Why We Build in Docker Containers

We are using Docker as a virtualization technology for our continuous delivery/deployment pipelines, in Rultor.com. We experimented with other technologies and Docker’s approach proved to be the best fit for our needs. Docker is a command line tool that can run a shell command in a virtual Linux, inside an isolated file system. Every time we build, we want to run build scripts in their own Docker containers, perfectly isolated from other builds in other projects.

There are three main reasons.

## Image Repository

Docker enables image sharing through its public repository at hub.docker.com. This means that after I prepare a working environment for my application, I make an image out of it and push it to the hub. That’s it. From now on, Rultor will use my custom Docker image with pre-installed tools and packages, in every build (merge, release, deploy, etc.)

Moreover, if and when I want to add something else to the image, it’s easy to do. I just start a container from the image and install Ruby into it. Then, I push a new version of the image to the Hub. On the next build, Rultor will pull a new image from the Hub and will use it.

Sponsorships Available

Sponsorships Available

Sponsorships Available

## Versioning

Every change to a Docker image has its own version (hash) and it’s possible to track changes. It is also possible to roll back to any particular change. With this feature, Rultor users are able to control their build configurations with much better precision.

## Application-Centric

Docker, unlike LXC or Vagrant or EC2 instances, for example, is application-centric. This means that when we start a container — we start an application. With other virtualization technologies, when you get a virtual machine — you get a fully functional Unix environment, where you can login through SSH and do whatever you want.

Docker makes things simpler. It doesn’t give you SSH access to container, but runs an application inside and shows you its output. This is exactly what we need in Rultor. We need to run an automated build (for example Maven or Rake), see its output and get its exit code. If the code is not zero, we fail the build and report to the user. Maven starts immediately. We don’t worry about the internals of the container. We just start an application inside it. This is what application-centric is about.

This blog post contains more technical details on this subject: Every Build in Its Own Docker Container

Yegor Bugayenko is an Oracle certified Java architect, co-founder and CTO of Teamed.io, lead architect ofrultor.com and jcabi.com, and a big fan of test automation. He is regularly writing about object-oriented programming, project management and DevOps on his blog at www.yegor256.com