Rodrigo Gonzalez CEO April 27, 2018 - 4 mins read Why continuous delivery should run in containers Want to deliver faster? Put your DevOps in a Container ... and call it DevOps-in-a-box if you like. The problem at hand The situation with the DevOps toolchain is that it just has too many moving parts. And these moving parts have become a cumbersome part of delivering applications. Have you stopped to think how many different tools are part of your pipeline? And how this is causing your delivery to slow-down? These might be some of the problems you could be facing when setting up your continuous delivery pipeline: Changes in the application require changes in the way it’s built/deployed New components require new tools Many build, test, and deploy tools have plenty of dependencies The container bliss Containers are basically lightweight kits that include pieces of software ready to run the tasks in your pipeline. When containers are used as part of the pipeline, they can include all the dependencies: code, runtime, system tools, system libraries, settings. With containers, your software will run the same pipeline no matter what is your environment. You can run the same container in development and staging environments without opening Pandora’s box. Containers are the way to be consistent in your CI/CD and releasing/provisioning practices. Other advantages of containers are: Containers can be versioned Containers can hold the most relevant DevOps infrastructure Containers are cheap and fast to run Ops can let Dev drive CI/CD safely (by giving Devs templatized containers) Clarive and Docker: what a combo! Docker is therefore a great companion to your DevOps stack. Docker containers allow your project and repository rulebooks to run pipelines alongside any necessary infrastructure without requiring additional software packages to be installed in the Clarive server. Clarive runs your DevOps pipelines within managed containers. By using containers in Clarive you can: Isolate your users from the server environment so that they cannot break anything. Version your infrastructure packages, so that different versions of an app can run different versions of an image. Simplify your DevOps stack by having most of your build-test-deploy continuous delivery workflows to run in one server (or more, if you have a cluster of Clarive servers), instead of having to install runners for every project everywhere. Clarive and Docker flowchart Curating a library of DevOps containers Using a registry is a good way of keeping a library of containers that target your continuous delivery automation. With Clarive you can maintain a copy of a local registry that is used exclusively for your DevOps automation. Defining “natures” Each repository in your project belongs or implement one or more natures. The nature of your code or artifacts define how they are going to be implemented. A nature is a set of automation and templates. These templates can use different Docker containers to run. For example, your application may require Node + Python, so two natures. If you have these natures in templates they will be consistent and will help developers comply to a set of best practices on how to build, validate, lint, test and package new applications as they move to QA and live environments. Running commands on other servers Clarive uses Docker for running shell commands locally. That guarantees that rulebooks (in the projects .clarive.yml file) will not have access to the server(s) running your pipelines. But you can still run shell commands in other servers and systems, such as Linux, Windows, various Unixes flavors and other legacy systems (including the mainframe!) using the host: option in the shell: command. How do I use my own containers If the container is not available on the Clarive server, the Clarive rulebook downloads the container from Docker Hub. So, to use your own containers, you have two options: Upload them to Docker Hub. Then use them from your rulebook. Clarive will download it on the first run. Install it on your Clarive server. On the first run Clarive will build another version of your container based on Clarive’s default Dockerfile, called clarive/your container. You don’t need to prefix clarive/ into the name, that’s done for you automatically. Manage all active Docker containers in your pipeline from within Clarive Getting started today Using containers is an important step in implementing a continuous delivery and continuous deployment process that is streamlined and avoids environment clutter. Head over to our 30-day trial and let Clarive to run your DevOps automation in docker containers for better consistency and easy setup of your temporary environments. Learn more about Clarive Docker admin interface with this blog post and learn how to manage containers and docker images. Share this:Click to print (Opens in new window)Click to share on LinkedIn (Opens in new window)Click to share on Twitter (Opens in new window)Click to share on Google+ (Opens in new window)Click to share on Facebook (Opens in new window)