Delivery pipeline for Docker containers

In a previous post I showed the usage of IBM Urbancode Deploy (UCD) to create a delivery pipeline for services packaged as Docker Containers. It was a positive experience. I liked docker as a packaging mechanism, I liked the concept of linking a test container to an application container as both a functional regression, as well as a health check and UCD did a good job of making the process of publishing to Docker registries and hosts repeatable and less error prone.

However, there were things that I did not like about the setup:

• Triggering processes from one environment to another was a manual experience. I did not so much have a pipeline as I had a repeatable way to deploy to a set of environments.
• It required users to be familiar with IBM Urbancode Deploy (UCD). While I think that UCD scores high on a usability rating it does take a few minutes to understand the concepts and relationships between Applications, Environments, Resources, Agents and Properties. I wanted something simpler that other team members would immediately understand.

Goals
When it comes down to it all I wanted was a tool that would allow me to check in a code change and then automatically trigger a pipeline. I wanted my pipeline to consist of the following stages that would be triggered by a checkin:

1. Source repository. Check in code to GIT
2. Private Docker Registry. Location where versioned containers could be found. Used for the source of deployments to staging, and also as a source for team members to get the latest version of the application for testing and debug.
3. Automated regression. Deploy Application Container, deploy linked test container and run tests. Discard any resources.
4. [ if Automated regression=passed] Staging. Deploy application container to a known staging environment. This can then be used for additional manual testing etc.
   
   Then additional deploy stages that would not be automatically triggered but could be requested.
   
   
5. Production. An environment used for the hosting of the application.
6. DockerHub. Public docker registry used to share the application with the world.

Demo


What was done
We setup a container service using Open Stack and some Docker drivers. Then configured a private docker registry behind nginx. We made some modifications with the help of the IBM DevOps Services team to support "Docker Builders" and "OpenStack Deployers", the scripted out each of the stages in our pipeline using shell.

Obviously, a lot of activity is happening around docker. I see simple multiphase delivery pipelines that provide a framework that we can continuous integrate, test, and deploy containers to docker cloud environments as a needed addition to the space.

Overall this was a lot of fun and I am encouraged by the simplicity of the JazzHub Pipeline. Check it out at http://hub.jazz.net/