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.
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.
Docker and Chef are not mutually exclusive. Case in point: 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).
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.
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.