A continuous integration environment is a mixed bag of machines, platforms, build toolchains and operating systems. Ideally, you want as much flexibility as possible in managing these environments. You want your build machines to be interchangeable and you don’t want to tie your builds to a particular machine. Using containers as build agents is an effective way to get the flexibility you need to create applications faster and more effectively.
Most modern software organizations recognize the benefits of deploying and managing applications as containers. And now more organizations are using containers to unify their build and test environments across machines, and to provide an efficient mechanism for deploying applications.
If you’re new to containers, think of it as the next step beyond virtualization. It consists of a set of platform-as-a-service products that use OS-level virtualization to deliver software in packages called containers. A container image contains everything it needs to run independently of the server on which it lives: It contains a copy of the operating system, along with your application. That could include a database, code, configuration files, dependencies, and so forth.
Containerization is a great way to simplify migration of Jenkins instances to different machines, as well as simplify ongoing maintenance and upgrades. Starting with versions 2.5 and higher, Jenkins Pipeline has built-in support for interacting with Docker from within a Jenkinsfile.
Although you can install and upgrade Jenkins using OS-installable packages, the container images of Jenkins take installation and upgrades to a new level, removing a lot of the complications with maintaining the Jenkins installation. That’s one of the main reasons you should prefer the container images of Jenkins over OS-specific installation packages.
Using containers as build agents for greater Pipeline flexibility
What about using containers in your build agents? You’ll recall that Jenkins agents are the "workers" that perform operations requested by the Jenkins controller.
Many of you have been writing Jenkins pipelines for awhile, but you’ve been constrained by the tooling that’s available on your agent. But what if you no longer had to be constrained by specific versions of specific tools on specific agents? And that you had full control over the tooling that you’re using just by having Docker available on your agents?
Well, that is exactly what’s possible by using containers as build agents for Jenkins. To learn how to set up your agents with Docker, watch this step-by-step video.
So why would you want to use a container as your build agent? As a pipeline author, it gives you the ability to define the tools and the specific versions of those tools that you want to use in your pipeline so that those items are not being mandated or managed by others.
Secondly, if in your environment, someone else has to install the tools for you on your agent, you can completely bypass all of that because you’re able to dynamically bring in the tools that you want or need at runtime.
Finally, it gives you the chance to experiment with different tools without having to make a long-term commitment to those tools. Because if you have a dependency on someone else installing tools for you, that might take a long time. But by running it as a container, you can test it out, and if it works, great! Then you have the option to work with somebody else to get static versions of those tools installed on your agents, or you can just stay with your container-based build agents.