[dexterbt1]

Ansible and Docker are orthogonal technologies. Docker buys you repeatable, application packaging to solve dev/prod parity. Ansible can then become your orchestration tool, doing the heavy lifting to manage not just containers, but hosts, dns, LBs, etc.

[drakenot]

But by using Docker, it does change the way you use Ansible, right? I'm not going to be executing Playbooks against a set of hosts anymore to configure them.

Instead, I guess I'll be using a Ansible to configure a container locally (in place of using Dockerfiles)? Then perhaps a different Playbook to deploy this container to my hosts?

[chetanahuja]

Note, container images are blobs of static content... programs, libraries etc. When they are running, they're akin to processes (or rather, actually are processes) running on a physical machine or a VM. Typically your build process will create docker container images (via some sort of CI tool perhaps).

Ansible is useful for automating tasks on an actual unix machine (VM or physical). Think of it basically as a parallel ssh to your remote machines.

So typically, you'd use docker containers to create reliable packages for your code and use ansible to do things like provision machines, change configs, run one-time commands on groups of machines etc. And yes, you can also use ansible to deploy your docker containers to your servers too. But that part is more manageable with tools like quay etc. which gives you nice things like package versioning etc.

[DanielDent]

One way I like to think about it: docker pull is the new apt-get

[jacoelho]

if you aren't setting capabilities, changing users and limits, and docker is a packing system

[crdoconnor]

Docker has a build file. They're not entirely orthogonal.

It's also not strictly necessary to ensure dev/prod parity.