Docker is an increasingly popular lightweight virtualization system. It has several advantages over virtual machines, such as having a declarative description of the file system, and it’s easier to deal with, starts up faster, and requires fewer resources in general.
In particular, the layered file system lets you deliver new updates to data centers and get updates from developers faster, and being lightweight means it is much easier and more efficient to run locally. There are images as small as 2 Mb—you’ll never find a VM image that small.
It’s also easier for developers and ops to create lightweight OS images with software already set up, and they can be run exactly the same way on both the developer’s machine and the test and production environments.
There are multiple ways Docker can be used. I’ll dig deeper into how it can help with testing in continuous delivery and integration (CD and CI) in certain cases.
The increasingly popular way of setting up a development process is a pull request-based workflow popularized by GitHub:
The new code can be directly deployed to the production environment (full CD) or to a test environment (CI).
When Docker is added to this workflow, a deployable Docker image is created during step one, which is the same image that eventually will go to production. It also usually can be pulled to a developer’s machine for debugging, to avoid the “But it works on my machine” issue. In this workflow, not only can all end-to-end tests be run on the pull request code under test, but they also can be deployed and tested by QA.
Docker Compose is a way to join several images to work in tandem, such as a web server and database in one compose. Using Docker and Docker Compose, it is possible to deploy the pull request’s code on a completely fresh environment with a fresh database, eliminating issues with contaminated data.
The alternative, more complex way to do the same thing would be by using Kubernetes, which is designed to deploy sets of images (similar to Compose) to production or test environments.
The ability for developers to use exactly the same environment that will be used in production helps to not only eliminate and debug environment issues, but also simplify and streamline delivery of the code to both test environment and production. The same image can be used on a developer machine as on a test environment and, once tested, can be delivered to production.
This also enables deploying those environments on demand and working with each image (potentially related to a code branch) separately, isolating any issues. This constitutes an effective shift left, which allows QA and developers to work much more effectively.
Artem Golubev is presenting the session Automate Your Application Test Deployments with Docker at STARWEST 2018, September 30–October 5 in Anaheim, California.
I'm passionate about automation and helping people to do less tedious work. Check out our system.