[Rapzid]

Configuration management is the Wild West with docker. The patterns and tools just haven't been established yet. Environment variables get nasty pretty fast. Some apps want config files and there is no standard way to deliver these to the containers at run time. Templating with something like j2cli can help. Of course you have consul-templates and confd but then how do you store ectd/consul in version control?! Managing a portfolio of customized containers and services require multiple of such is a PITA. All roll your own solutions. Every app repo becomes its own Ansible playbook or chef cookbook, only crappier.

Docker is pushing CM out to the individual applications, but the tooling just isn't there yet for it. I suspect an area of major growth and change is going to be around managing container builds and portfolios. The way we are doing it now is not the way we will be doing it in a year or two. We are in the pre-puppet/chef days.

And that doesn't even touch on orchestration, which something like Ansible or Salt can help out with. Ultimately docker doesn't even really attempt to address any CM problems, and in a lot of ways it makes the challenges even harder.

[dexterbt1]

Totally agree here: the patterns and the tooling are not quite there yet.

The concerns you raised are exactly the areas we struggled in when we moved to Docker. Our newer apps tend to be written with containerization in mind, though we also wanted and are porting older/legacy apps to take advantage of containers.

1. I somewhat liked 12factor's env-vars-as-config for its simplicity and ease of use but there are limits to its flat key-value string-only structure, not to mention the debatable security concerns that may arise when storing secrets in them.

2. Some apps, esp legacy ones, need files for their config, especially those that are costly/harder to rewrite/reintegrate. Config files benefit from being easily versioned, can be templated (Ansible's jinja ftw!), not to mention the richness of syntax/structure in can give (xml/yml/json/bin/etc).

3. We sometimes do a hybrid approach of doing a "source envfile.sh && exec binscript" as entrypoint of our containers, with envfile living in a mounted volume, managed by a CM tool.

4. There are lots of innovation here in specialized tools such as confd/etcd/consul/skydns but completely agree that versioning is a real concern. I like the heroku/deis-style approach of creating a new release for each change in the config. Bonus points to easy rollback on a previously working config (whatever system you're using, be it env files or config files).

5. As with projects/whole-stacks of multiple containers/hosts, I like the rancher/maestro-ng/docker-compose style of managing your system stack. Next wishlist for this would be a stack with support for pinned versioned docker images + smart rollback/rollfwd support for each config change anywhere in the stack.

Ansible filled this gap for us: we have a git repo per project, various playbooks for deployment/lifecycle-management of docker containers, with multiple environments supported (dev/qa/prod using same playbook), support for multiple maintainers and secrets management via ansible-vault. This is workable for us on a few projects, with small scale/set of hosts/containers.