phunehehe.net

Docker vs Chef and Vagrant

Docker seems to be the new hotness in the devops world. It runs applications in isolated containers, providing the benefits of virtualization without the hassle of virtual machines. Today is a Cogini Hackday, and I chose to dive into Docker. This is still a very young project, but it has the potential to change the way we do software development and deployment. I’m going to compare Docker with Cogini’s current best practice :)

Chef and Vagrant

At Cogini we use Vagrant and Chef extensively for both development and deployment. We maintain cookbooks that can be used in Vagrant machines, development, staging and production servers.

Developers and designers can clone their project and vagrant up, skipping the hours (and sometimes days) needed to set up the right development environment for the project.

Sysadmins can clone a project on a server and provision with Chef, avoiding human errors like “Oh I forgot to set up the cron job”. The cookbooks also serve as deployment notes.

The Chef+Vagrant workflow is roughly as follow:

  1. Identify project components (data stores, programming languages, libraries, development tools etc.)
  2. Write Chef cookbooks that combine all components into a ready-to-use Vagrant machine
  3. Get the source code and provision your own Vagrant machine
  4. Perform development tasks, modifying the cookbooks as needed
  5. Deploy by cloning/updating source code and (re)provision

Whatever can be done with Docker, I wish to keep the nice productivity enhancements that Chef and Vagrant give us.

Meet Docker

When I first saw Docker, it was hard to resist the obvious thought “I already have Chef and Vagrant” but I was inspired to see a comment of the Vagrant creator on Docker. I mean this guy Mitchell who created Vagrant which is awesome is saying that Docker is awesome, so it must be pretty good right? Here is what I found interesting in Docker, initially:

  • Because it doesn’t involve virtual machines, startup time and resource usage is much better than Vagrant.
  • Because it eliminates the need to start from an empty server, you no longer have to spend time writing, testing and debugging Chef cookbooks.

With a view to compare with the existing workflow, I tried to come up with a Docker workflow and here is what I figured out after following the examples:

  1. Identify project components (data stores, programming languages, libraries, development tools etc.)
  2. Prepare a Docker image with all components
  3. Get the Docker image and start doing development tasks, creating new images as configurations change
  4. Deploy by getting an image and starting a container from it

Does Chef fit in here? I think I’d still use Chef to set up the images, just so that I have an audit trail of changes to the image. Or maybe I can set up the images manually, track the changes elsewhere and forget about Chef.

Workflow Comparison

Where Docker is better:

  • No need for provisioning. Having to wait for 5-15 minutes before you con start/continue working is not too bad, but annoying and unbearable at times.
  • Snapshots for free. Every time you use run on an image a new container is created. Each container is essentially a snapshot of the application state that includes all configurations and data so it’s easy to roll back.
  • A new deployment model. Right now it’s not really ready, but it full of potential. More on this below.

Where Chef+Vagrant is better:

  • Keep source code and deployment information (cookbooks) in the same place. It’s easy to overlook this, but I have found it incredibly useful to have easily accessible deployment notes without having to hunt down someone who may know the details.
  • Stable and standardized tools. As of this writing some pretty useful functionalities are still missing from Docker (for example, the ability to copy files from the Docker host to a container). Even when Vagrant was version 0.x everything was almost perfectly usable. I guess being similar to the conventional VPS model helped.

Interesting Potential

For obvious reasons I won’t attempt to use Docker in a production environment yet, but I can already imagine what might happen.

Docker will do to VPS what VPS did to dedicated servers. When people realize they can do everything they need on a cheap and flexible VPS, many will choose that instead of dedicated hardware. Then many people choose to use Heroku so that they don’t have to manage their own VPS. It remains to be seen how Heroku will compete with the opensource Flynn.

Separation of each container also sounds nice. Maybe the next trend will be one container for each service, instead of one VPS for each app. And then each of those services can be scaled at will, not affecting others. So you can start with one Docker host running multiple services each in its own container. Then when you need, add another Docker host and have more containers running the services needing a boost. Of course I’m assuming you design your app to scale out ;)

Questions or comments can go to Google+ :)