Is there any reason to use Puppet alongside with Docker? [closed]

I have tried Ops part of DevOps some time ago and it was quite fun, but I haven't time and reason to try it in any project. But last week I started new job, where boss asked me if I can configure server to make something like staging environment for company projects. Alongside with that I;ve started thinking about migrating project to be more DevOps rather than only dev.

I've come out with Docker which is great and super easy for me. But some time ago I was trying Puppet, so question come to my mind: "Is there any reason to use Puppet with Docker?". Docker seems doing all things that Puppet would do, but in easier way.

PS Some time ago on Hacker News there was Consul which is nice configuration and service discovery, so even configuration can be resolved (and I'm thinking about implementing this too).

Solution 1:

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.

Solution 2:

Docker helps you to provision and initially configure containers, but it runs one-time commands at the initialisation of the container.

Puppet is strongest when you run it as a daemon, it ensures that your configuration stays as you specify it, so for example if you service stops running, it will start it again.

One of the best things about (correctly designed) puppet configuration manifests is that they are idempotent; it's supposed to describe the state you want to be at and not so much necessarily the steps to get there.

It also allows you to abstract and parametrise configurations and you can export parameters created on one server or container and use them in another (e.g. collecting a list of nodes hostnames for a monitoring application).

I would say they definitely serve different but related purposes. I'm currently looking at using existing puppet manifests to start configuring containers so that development environments are more like production environments.