Docker has seen widespread adoption as an infrastructure automation tool and there has been a growing debate as to whether it supersedes configuration management (CM) tools. With most CM tools providing support for Docker, the consensus seems to be to use both CM and containers in tandem for without ditching one in favor of the other.
Configuration management tools aim to ensure that all members in a fleet of servers are at the same baseline state over time, incorporating configuration changes as they happen. CM also solves the problem of configuration drift, where the configurations of running servers become different over time from the intended baseline. CM can solve this but only if every change is done through the CM tool. Modern applications have hundreds of thousands of servers and these tools make it easy to manage them at scale.
However, in recent years greater elasticity has become the norm and application architectures have evolved into API driven service oriented ones. This move from monolithic to microservices architectures, the need for immediate service discovery, and increased speed of scaling up and down raises new challenges that push the boundaries of configuration management.
Container technology makes it easy to create immutable servers with the required configuration and recreate them on every change while throwing the old ones away. Compared to CM, containers look like an easier model to work with - just "bake" the image with required dependencies and roll out the nodes. Netflix had adopted this model long ago with their Amazon EC2 AMIs. An AMI (Amazon Machine Image) is an image from which a server can be booted. In general, these are known as golden images.
Containers also make microservices architectures easier. Any service-oriented architecture will have inter-service dependencies. These dependencies can be complex for applications composed of many services. An orchestration system for these services needs to be aware of the topology as well as the dependencies. Docker can achieve this kind of service modeling. Ernest Mueller, a long-time member of the DevOps movement and co-author of the agile admin blog, explores this:
The pressure of the dynamic nature of these microservices has meant that actual service dependencies have to be modeled. Bits of software like etcd and docker compose are tightly integrated into the container ecosystem to empower this. With tools like this you can define a multi-service environment and then register and programmatically control those services when they run.
This is in contrast with pure configuration management, which, he adds:
just lets you change the software and the rest is largely done by inference, not explicit modeling
So is the golden image paradigm a panacea? Will containers replace configuration management?
Ben Schwartz, architect at BancVue and blogger, sees no point in the debate, as CM and containers solve fundamentally different problems according to him:
The tired old debate of “Containers vs Configuration Management” is rooted in fallacy. We’ve never tried to solve all of our problems with one technology before (You wouldn’t pull down your Java libraries with Puppet, or keep your load balancer config in Maven Central), so why do we have to start now? Instead, I recommend we do what we always do: Choose the right tool for the right job.
CM tools are for deployment and change management. Containers are a lightweight version of virtual machines which enables the loosely coupled microservices architecture of today’s applications more easily than virtual machines. This is one clear benefit of containers but it does not mean CM does not have a role in such architectures.
CM tools can be used for multiple things in a containerized environment:
- Base image creation and provisioning, e.g. Chef and Docker, Ansible and Docker,
- Managing the configuration inside running containers
Diego Zamboni in his talk at the 2014 USENIX Configuration Management Summit summarized their co-existence, saying:
The future of configuration management in the age of containers is to still do configuration management inside each of those little pieces.
Where the “little pieces” refer to the building blocks in a containerized system - applications, container images and the containers themselves, and he also asserts that we should get out of this immutable infrastructure point of view
. His wish list of attributes for in-container CM systems includes lightweightedness, distributed and resilient, keeping in mind the ephemeral nature of containers.