BT

The Role of Configuration Management in a Containerized World

| by Hrishikesh Barua Follow 15 Followers on Dec 02, 2015. Estimated reading time: 3 minutes |

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:

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT