

Why Docker? Why Not Chef? - scottbessler
http://blog.relateiq.com/why-docker-why-not-chef/

======
gexla
It's not either or.

I don't know about Chef because I have never used it. I use Ansible, which can
be used for much of the same things.

Obviously Docker itself is for managing containers. The Chef-life capabilities
are the building, repoing of images, and config files that you use with
Docker.

Once a container is running, then Docker's job is to keep the thing up rather
than making changes to the existing container. That's where something like
Ansible might come in. Anything else you might want to automate after the
container is already running could be handled by Ansible. For example, maybe
you want to force a DB backup on all your X containers, then you could run an
Ansible playbook to do that. There isn't anything in Docker which would allow
for that.

I like the flexibility of Ansible as a general tool, so I prefer to keep my
server setup recipes in Ansible. Even if I don't have to use those recipes
often because I only need to setup one base image for each need, I still like
to have that Ansible playbook. I haven't tried all the new features of Docker
yet though. I had a back off a bit a few months ago because I couldn't keep up
with all the changes.

~~~
scottbessler
Yeah, Ansible is something we are strong considering for managing docker hosts
and container instantiation. As for building and provisioning containers, I
would still argue that Dockerfile is superior for most of the work that needs
to be done. Runtime configuration file templating is definitely something I'd
like to see included in a Dockerfile definition, but until then at RelateIQ we
are looking to a simpler solution than Chef for that and Ansible looks
promising in this regard as well.

------
gabrtv
Docker and Chef are not mutually exclusive. Case in point:
[http://deis.io/](http://deis.io/) is a PaaS that uses Chef extensively for
orchestration of containers. There are other approaches that don't use CM
(e.g. CoreOS) but they are still very early.

I do agree that Docker makes Chef less appealing for automating deployment of
applications that should be containerized -- most web apps, Redis, etc.
However, Docker is not yet suitable for every workload. For example, if your
application/service has complex storage or networking requirements, Docker may
not be a good fit (yet).

------
cryptolect
I've been through the same love/hate of using Chef, and have come to replace
it with Docker. As a solo dev I have a bunch of services to configure and
maintain, and Docker is incredibly easier[1] to work with in comparison to
Chef.

[1] For my specific use cases.

------
shykes
For a perspective on how to use Docker _and_ Chef together, this article is a
good starting point: [http://tech.paulcz.net/2013/09/creating-immutable-
servers-wi...](http://tech.paulcz.net/2013/09/creating-immutable-servers-with-
chef-and-docker-dot-io.html)

------
golubbe
Interesting post. Looking forward to seeing RelateIQ present on this at the
meetup at MongoDB this afternoon.

