Want to learn more?

I’ve heard this question asked many times since DockerCon 2014. Docker adoption has been meteoric over the past three years, but containers in production are still proving to be a challenge. In December 2015, Robin Systems surveyed 200 representatives from various industries about their container adoption status. Of the respondents, 36 percent are running containers in production, and 59 percent are planning to adopt, are still investigating, or are simply playing with containers.

At Demonware, we have been using Docker for over two years. However, we’re still very much within the “planning to adopt, still investigating, or simply playing with containers” category. Why is the jump to production so difficult? Is there a way to massage containers into production in a low risk, low cost manner?

As a member of the Build Engineering (BE) team, I have worked with development teams to Dockerize their continuous integration (CI) pipelines. When the BE team started using Docker in September 2013, we almost unanimously agreed that we could leverage containers in build, test, and development environments without a hard requirement to run containers in production. Our attitude has since changed.

The benefits of containerizing our CI pipelines, tooling, build infrastructure, and test infrastructure have been immense. We would like to see these similar benefits in production. So what is stopping us?

Most of the barriers aren’t technical. There is still concern in some quarters that containers are not the right technology to use. We wanted to move forward while re-assuring concerned parties that we are doing so in a controlled and low risk manner.

Dual Deployment

The plan was to tweak the existing continuous Delivery (CD) pipeline to move containers closer to production without any risk to existing deployments. We already had a number of disparate build pipelines responsible for building service packages (RPM), service containers (Docker), and Amazon Machine Images (AMI).

We combined theses pipelines to produce a “dual deployment” AMI artifact. This AMI artifact is created using Packer. Packer is a wonderful tool for building and provisioning images of any type and supports a wide range of providers and provisioners. Packer is completely free and provides reliable, repeatable images based on a JSON format template. A sample template can be found here.

The service package (RPM) is installed, configured and ready to run when the EC2 instance is started.

The service container, based on the same source as our service package, is built during the AMI build stage.

Benefits

This allows us to deploy our service in the usual manner but also have the option to route traffic through the service container for testing purposes. This required a small tweak to the AMI Packer template and extended the build time by a few minutes.

This is a low risk method to get containers into production by piggybacking the existing CD pipeline. Starting the service container is still a manual task, and we currently use this to test the container. When we start the container we use the --host docker run option to route traffic through the service container.

Let’s walk through what an example of the flow and a sample Packer template for AWS might look like.

An Example of Dual Deployment

In this example, our service is installed on an EC2 instance (Centos 7) and can handle traffic using the VM interface. The same code is containerized and available to handle traffic using the host (VM) interface. Currently, we manually redirect traffic for the purposes of testing.

Building a dual deployment environment using Packer

The Packer template aws.json is used to build an Amazon Machine Image. This image will be bootstrapped, our service will be installed as an RPM, and our service container built.

The bootstrap.sh can be as simple or complex as you need it to be. We use it to install some helper tools and install Docker.

The container.sh pulls the service container code from GitHub and builds the container images as part of the AMI build. The aws.json template supports six arguments:

base_image : The AMI ID of the base image you want to build from.
new_image : The name of the new AMI you are building.
access_key : AWS access key
secret_key : AWS secret key
script : The name of the script you want to run to bootstrap the base image.
script_args: Pass in additional arguments to the script.

Create a Primed Centos 7 AMI which includes both the service and service container:

When the build command completes successfully, you will have an AMI with the service installed and with the service container built.

Our CD pipeline has supported AMI builds and RPM-based service installs for a while. We wanted to run a single containerized service with as little disruption to the existing pipeline as possible. By tweaking the Packer templates, we had a simple, low risk way to get our containerized services into production.

Conclusion

We are currently at the point of testing our containerized services in these ‘dual deploy’ environments. Some of the fear and stigma of putting containers into production has been removed. We understand the deployment of containers better, and we are piggybacking a well-defined CD pipeline.

This post doesn’t aim to solve any technical barriers to deploying containers in production. It is merely proposing a way to use existing processes to introduce containers into a CD pipeline in a low risk manner.

So often the first step is the hardest; this approach may provide a less intimidating way of getting your services closer to a containerized future in Production.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles. Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.

We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.