Before we talked about how a Rails app can be Docker-ised. In this article I am going to show how a deployment process can be done with Docker Cloud.

Docker Cloud is a nice platform for managing running services and applications. As you may already know, to deploy an application with Docker firstly an image should be built and pushed to a registry (so it automatically becomes part of a deploy). From there, Docker Cloud will be able to deploy it (run on connected servers). However, these steps to build and push can become inconvenient in large teams unless some CI work is implemented.

Let’s say you have two main environments: staging and production. Using Docker you should assume that the container is environment independent. Usually a new version of an app is deployed on staging first for some testing and thereafter on production.

So here is an example of commands to make a deployment simple and automatic (script is from Jenkins but the idea can be used anywhere):

#!/bin/bash -l
sudo docker build -t organization/application:${BUILD_NUMBER} -t organization/application:latest .

sudo docker push organization/application:${BUILD_NUMBER} 
sudo docker push organization/application:latest

As you can see, the first command builds two images: one with a latest tag and the second one with a specific number (BUILD_NUMBER is just an incrementing variable for each execution). The second image is always built fast thanks to Docker cache. Organization should be replaced with the name of the Docker Cloud organisation/DockerId and instead of application, you should use the container name used on the cloud platform.

What are the benefits of such an approach?

When a staging service is set up on Docker Cloud, it is possible to select a container name with a latest tag for it to be used and to enable the Autoredeploy option.

Thus, each time a new container is pushed to a repo, it will be automatically redeployed on staging.

In most cases production deployment is desired to be done manually. To do this only a few actions are needed for the production service: select a container tagged with a required version -> redeploy. Having it under a specific number will make reverts easy. If something goes wrong during deployment, a container with a previous version number may be selected and redeployed in less than a minute.