> It means that when you build Docker containers, it makes good sense to install a CM tool and use it to do the systems configuration.

If you belong to the "one container, one process" camp, I'd say CM has little utility.

Let's say we have a redis image. Using a CM I'd have to:

  * install ruby and various ruby lib pkgs
  * install chef or puppet, and a multitude of rubygems 
  * add recipes/manifests

My image is now several times bigger than it need be, and the configuration is now more opaque, in several files. It's a pain to debug and troubleshoot when something deep inside the recesses of chef-solo fails. And why would I?

I'd rather have a dockerfile with `apt-get update && apt-get install -y redis-server` and perhaps a line adding a custom config file. Very readable.

Appreciate the comment. The point I was hoping to get across wasn't that Docker would completely replace CM (or that CM is a bad thing), but that it could help reduce the amount of work in the CM world. As mentioned, we still needed to use Chef anyway (and using Opsworks to get a head start), so at least in this kind of environment CM is still necessary. That said I can see how the article could be slightly misleading =)

I appreciate your response, but -

When you discuss CM being necessary, you are talking about using it on the host and not within the container.

Ultimately, operability and proper configuration inside the container is critical. Using a Dockerfile with no CM inside it is not much of an improvement on not using CM anywhere.

You don't need stateful CM inside the container. It's fine to fire and forget - use Puppet in apply mode or Chef solo. But there's a reason these tools are used in building AMIs and containers over scripting languages - we've come a long way over the past 10 years, and I still feel that switching to the Dockerfile as a configuration mechanism is like moving back to configure/make/make install.

What else do you think is happening under the hood when you use a CM tool like, say, Ansible? Ansible translates your configuration to small Python scripts, uploads them to the remote host and runs them.

What I'd like to see is a "script dump" output that still lets you create your yml configuration but converts it into shell scripts that you can call from your Dockerfile without any dependencies.

Of course, now you have an additional build step... and what could you use to tie everything together? make/make build :)

What happens under the hood is almost irrelevant, because it's predictable and repeatable.