How Docker is Changing Configuration Management

With configuration management, there have always been two camps: Bake or Fry?
When it comes to what are traditionally considered configuration management tools, Chef, Puppet and others, these usually fall into the fry camp.  This approach involves dynamic configuration at deployment time.  Meaning, you have a server and need to configure it for the first time,  including permissions, installing packages, etc.  This is where the common CM tools excel.

Bake involves taking a base image, and configuring that base image at build time, which essentially outputs a fresh “golden” image with which you reconfigure all of your servers.  To initially create the golden image you would configure it using Chef/Puppet/Bash/Shell scripts, you then take a snapshot of that specific configuration.  Then when you need to provision new servers, you use that one single golden preconfigured image.  In this scenario nothing is dynamic.

Docker orchestration out of the box – just shake and bake with Cloudify.  Go

Up until recently the fry method has been the most common for two main reasons.

1. Before cloud and dynamic environments, most people used physical servers that are a mutable living thing.  Which means they would change regularly, and more often than not, things would break.  The ability to do wipe and start over from scratch was non-existent.
2. To help overcome this common pain point,  you needed to tool  to help you restore states or “converge” when things went wrong, e.g. roll back a bad update, and misconfigurations and such.  CM tools were developed for just this purpose, and aside from the basic provisioning, one primary feature is the ability to converge and restore states.

The bake methodology started to gain momentum following the onset of cloud.  Where, in the absence of cloud – or rather a reliable, simple way of packaging the state of a configured system, people used to fry their images.
However, the problems with frying images are much bigger than with baking, since you can’t really restore states and return to base images very easily.  So what you wind up doing is continually converging and restoring previous states, once the state of certain server is compromised.

That’s why the typical use case of CM is configuring the system at the start, and then the tool’s client usually wakes up every 15 minutes or so and checks if the state has been compromised.  If so, it will then go ahead and restore it.
With bake, if a system is compromised, you wipe the existing running server and start with a clean state from scratch with your golden image. See this very interesting article on this.

So why Doesn’t Everyone Use Baked Images?

Until now, before the Docker container revolution, you needed cloud or VMs to take the baking approach, since you can’t install a full OS on bare metal on every deployment (at least that’s the case for most organizations).
In order to bake images in a reliable way, you need to capture all the changes made to a certain system – OS level, file system etc. etc.., and the only reliable way of doing that, was through VM images.  So those able to do so were only those who used VMs or cloud.  Another reason, is that even when using VMs or cloud, when you bake an image, the artifact is very large.   It can range from a few GBs to a few tens of GBs, making the process very cumbersome. Until Docker.

When speaking about Docker people tend to focus on the containerization aspect – which in itself is an incredible breakthrough – but this creates a huge glaring blind spot to another and possibly even more exciting aspect of Docker.  Docker has the ability to capture changes made to all levels: OS, file system etc. and create a portable image that can then be deployed on any Docker-compliant system, which includes most Linux flavors.

So What’s Changed for the Baker?

Docker images are much more lightweight, are easier to create and automate the creation of,  than VM images.  Docker also has a change management mechanism, so that every change you make to the image is captured.  This makes it possible to easily roll back changes, and update the most recent changes (i.e. just the delta to your build), instead of having to build the entire image from scratch every time.  It functions very similar to git, where every commit has a unique identifier and you can actually revert last commits individually, so you don’t have to revert all changes. What’s more, they’re not limited to VMs, and can run on physical servers, as well making all of this available to a much wider audience of users.

This ability to do incremental work on images, are going to change the configuration management game.
So…how does this ALL apply to bake vs. fry?  When Docker created their version of bake it was suddenly much more accessible to the average user.

Where Is It All Going? 

The ability of tools like Chef and Puppet to do convergence is becoming less exclusive, when you don’t really have to converge anymore, and you can essentially just settle for a simple script that bakes your Docker images right up for you, and can even roll back changes on demand.

What’s Next?

Leveraging Docker for complex deployments will kick Docker up a notch.  That said, to do so, you will still need orchestration on top to tie it all together – as Docker is purposely built in such a way to hold self-contained parts of apps – and these often times need to communicate.
In our next post we’ll discuss Docker orchestration, and our new and nifty plugin to make this easy as pie.