Several months ago I was having a conversation with a friend about our Chef workflow for managing and provisioning servers, as well as provision our local machines using Vagrant. That conversation led to us talking about Docker, and how Docker is going to change everything in the devops space. It was after that conversation that I got a hold of The Docker Book, and started getting up to speed with Docker.

We don't have a concrete process in place yet, but I want to share my thought process in creating a Vagrant / Docker workflow that will work for our team (and hopefully get valuable feedback from others that are thinking about the same things). This post is part 1 of a series of posts to hash these ideas out.

Background

We are a long time user of Vagrant. Most of our projects include a Vagrantfile, which allows us to just type vagrant up inside the project folder, to provision a local environment and start developing on. We have used both Puppet and Chef as provisioners to setup the entire local environment.

We have also implemented various deployment processes via chef-client, capistrano, and packer.

The packer workflow we use isn't entirely open source, as there is one key component of that workflow that hasn't yet been open sourced, but I've heard from our client that they will likely be releasing that tool to the public.

Objective

My goal is to create an end-to-end process, using docker, that encompasses all the automation we are used to having with local environment setup, and full-blown virtual machines. I also want an easy way to automatically create deployable docker images (with our application baked into the image) upon each code release, like what we're used to with the packer workflow we use. We would likely push these images (artifacts) up to a private docker hub.

It would also be great to have a command line tool (probably using fabric) that facilitates creating new containers on a specified docker host from the freshly baked docker image, cycle in the new containers and turn off the old containers (probably using HAProxy). The tool should be able to handle rollbacks as well, turning back on older containers, and the tool should also clean up after itself, removing containers that are more than 5 releases old.

To be continued...

I have a lot of ground to cover over the next few posts in this series. I'm not sure where we'll end up, but hopefully this post outlines where I want to go with our docker workflow. Stay tuned for upcoming posts in this series including:

• [Using Vagrant with a Docker Workflow - Part 2]({% post_url 2015-07-19-docker-with-vagrant %})
• [Setting up a Docker development environment with Vagrant - Part 3]({% post_url 2015-09-22-local-docker-development-with-vagrant %})
• [Using Jenkins to bake images in a Docker Workflow - Part 4]({% post_url 2016-01-20-jenkins-build-docker-images %})
• [Deploying containers with Kubernetes - Part 5]({% post_url 2018-08-26-deploying-docker-containers-intro-kubernetes %})
• Load Balancing containers with Kubernetes Ingress - Part 6

Note: I will update the above list with links as the posts are written.

Until then, I'd like to hear what others in the Docker community are doing in terms of CI / CD. Leave us a comment!