I think one thing to keep in mind about Ansible is that it's an orchestration tool that also does configuration management. We've integrated Ansible into our workflows in such a way that it kicks off everything we need to do, even if that involves just coordinating some info between APIs. We don't mutate containers at all - merely get Ansible to make things happen around their deployment and communication.

How do you use ansible to deploy your containers, if I may ask ? We're looking into the docker module right now, but I don't know if it's good or what. Currently we're launching container via systemd and manage the unit files with ansible.

We're running all the containers on Mesos hosts, so really all Ansible needs to do for us is talk to Marathon. We realized early on down this path that to accommodate scale we'd need to have some sort of scheduler. Mesos happened to be the most robust.

We originally tried the docker module in Ansible but found it had a few problems. There's been a lot of work on it since, and I expect it will be in a much better state when Ansible 2.0 is released.

Well, there's a couple of scenarios:

- Long-running processes where they don't want to destroy and redeploy every single time a fix or change gets deployed

- One is where they try to reduce the configuration sprawl by making configuration changes at runtime using something like ansible

- One is straight-up bigco stupidity (we must have a way to change the running configuration of a system because the audit team says so)

- separation of responsibilities - we have one team that builds "approved" docker images, and then dev teams can make changes based on that - it might be easier to deploy changes at launch time

Again, I'm not saying all of these make sense, but back when I was workign on docker strategy and interviewing really big companies, these are the types of concerns they had about implementing docker at scale.

Containers are useful as an alternative to full VMs. I use LXC on Ubuntu, and I edit software and packages on my containers as I would a normal VM.

Maybe that's not standard with Docker specifically.

It's lighter-weight than virtualization but provides many of the benefits, even if you mutate running containers.

Config file changes rather than code changes. Version of the software stays the same, so you just have to restart it.

But one of the central points of Continuous Delivery is that there is no difference between "configuration" and "code", and that changes for either of them will result in a new release candidate. Every release candidate goes through the same automated quality checks before going to production.

Managing the container hosts.