Puppet and docker can do many of the same things, however they approach them in a different way.
Puppet manages files + packages + services. (Called the trifecta). Docker encapsulates binaries and configuration files inside of a container.
At the time of this writing, docker is still unstable and shouldn't be used in production. Many of the API's are likely to be changed until version 1.0 is released.
Even when docker does become stable, it will be a large undertaking to convert every process and config file to docker containers.
Puppet on the other hand is a stable product and comes with an entire ecosystem of tools (heira, mcollective, facter, razor). These tools can be implemented quickly and without worry of things breaking.
I would highly suggest the following resources.
A video of how to manage application stacks with puppet
https://www.youtube.com/watch?v=KSo_mcJxFIA
A podcast about how docker and puppet can work together
http://devopscafe.org/show/2014/1/23/devops-cafe-episode-46.html
A puppet blog article on how to integrate with docker
http://puppetlabs.com/blog/building-puppet-based-applications-inside-docker
Another blog article on puppet and docker coexisting
http://puppetlabs.com/blog/can-containers-and-configuration-management-co-exist
A puppet module for interacting with docker
http://docs.docker.io/use/puppet/
A minor correction on the terminology of devops. Devops is more of a software development methodology where developers and operations cooperate, than any specific tool.
Update
Currently my company uses both puppet and docker. Here is a great presentation given at puppet conf 2014 on why you would use puppet vs docker. Given by James Turnbull, a former employer of puppetlabs and the author of the docker book.
https://puppetlabs.com/presentations/using-docker-puppet-james-turnbull-kickstarter
Also a good short video tutorial on docker given by sysadmincasts.com
https://sysadmincasts.com/episodes/31-introduction-to-docker
Docker Pros:
- Can spin up instance quickly
- Easier to learn than puppet
- Easy to do 0 downtime
Docker Cons:
- Containers have 10GB limit when using the devicemapper backend
- Small configuration changes take a long time to rebuild the container
- Costs money to use a docker registry like hub.docker.com, quay.io (The self hosted docker registry is extremely buggy, and has no gui)
- No proper init system. Some applications don't play nice.
- No fine grained control over network
- Applications that require subshells (looking at you RVM + ruby) are very tricky to get working properly
- Can't manage windows hosts, no SLES or other less popular operating systems
- Currently docker orchestration is very young.
- Currently can't set your /etc/resolv.conf at build time
- Various bugs which we have to mount /etc/localtime and /dev/urandom to map to the hosts localtime and urandom directories.
- Performance is not as fast (despite all the claims that docker should be 99% the speed of bare metal, it is sometimes 30% slower than other machines).
- Small containers still have hundreds of megabytes of overhead. Our containers are all multiple gigabytes.
Puppet Pros:
- Easy to scale
- Works with existing servers (windows, linux, sles)
- Fast to make small changes
- Strong community of other puppet users and modules
- Standardized API for installing packages on all platforms
Puppet Cons:
- Large infrastructures get very complex
- Conditional module dependencies create spagetti code
- More heavy weight
Currently we use puppet to provision our docker containers. The docker containers are used for jenkins builds and are destroyed after each build. It works well, and gives us a consistent environment. That means that we only have to write the code once, and then rebuild both ubuntu, sles and centos machines. Rebuilding the containers takes about 15 to 30 minutes and is still a manual process. Docker is great for spinning up quick test vm's,
So in short, puppet is great at managing your existing infrastructure. Docker is good if you have a greenfield that is 100% linux with a technology stack that can be enclosed in small ephemeral instances. While some of the functionality overlaps, they are not mutually exclusive.