Docker and Configuration Management

Since Docker was announced there have been a lot of discussions about where Docker fits with configuration management tools like Puppet and Chef. I spent a bit of time this week thinking about scenarios, images, management tooling and talking to people about how they use Docker, either with or without configuration management tools. I didn’t learn any startling insights but I did decide that, like most aspects of the domain, there is a lot of room for a lot of tools.

Docker is first and foremost an image building and management solution. One of the largest objections to the “golden image” model is that you end up with image sprawl: large numbers of (deployed) complex images in varying states of versioning. You create randomness and exacerbate entropy in your environment as your image use grows. Images also tend to be heavy and unwieldy. This often forces manual change or layers of deviation and unmanaged configuration on top of images because the underlying images lack appropriate flexibility.

Compared to traditional image models Docker is a lot more lightweight: images are layered and you can quickly iterate on them. There is some legitimate argument to suggest that these attributes alleviate many of the management problems traditional images present. It is not immediately clear though that this alleviation represents the ability to totally replace or supplant configuration management tools. There is amazing power and control to be gained through the idempotence and introspection that configuration management tools can provide. And Docker itself still needs to be installed, managed and deployed on a host. That host also needs to be managed. In turn Docker containers may need be to be orchestrated, managed and deployed. Often in conjunction with external services and tools. All capabilities that configuration management tools are excellent in providing.

It is also apparent that Docker represents (or perhaps more accurately encourages) some different behaviors for hosts, applications and services: short-lived, disposable, and which more often than not focus on single services being provided in a container. These behaviors do not lend themselves or resonate strongly with the need for configuration management tools. With these behaviors you are rarely concerned with long-term management of state, entropy is less of a concern because containers rarely live long enough for it to be, and the recreation of state may often be cheaper than the remediation of state.

But I don’t believe all infrastructure can be represented with these behaviors. Much of it can, and perhaps in future more of it will be, but it’s not exclusive and will likely exist alongside more traditional infrastructure deployment.¹ The long-lived host, perhaps also the host that needs to run on physical hardware, still has a role in many organizations.² I’m also starting to see Cloud and virtual machine consumers, especially some of those on Amazon, with long-running instances whose uptime is measured closer to the traditional physical hosts they used to operate.³ As a result of these diverse management needs, and combined with the need to manage Docker itself, I think we’ll see both Docker and configuration management tools being deployed in the majority of organizations. Indeed I can see the potential for some incredibly powerful deployments tools that combine containers, configuration management, continuous integration, continuous delivery and service orchestration.⁴

Disclosure: I was an employee of Puppet Labs and have a financial stake in the company. I am also working on a book about Docker.