DevOps Zone is brought to you in partnership with:

Matthew is a Linux Consultant and Systems Administrator specialising in removing human error from configuration and deployment through the use of automation. He has supported systems of all sizes, from small businesses to home entertainment and major cloud providers. Matthew is a DZone MVB and is not an employee of DZone and has posted 9 posts at DZone. You can read more from them at their website. View Full User Profile

Puppet vs. Chef – The Devops Deathmatch

02.20.2012
| 8422 views |
  • submit to reddit

LAAAAAAADIESS ANNNNDDD GENNNELMEN…… LET’S GET READYYYYYYY TO RUMMMMMBBBBBLLLLLEEEEEEEE!!!!!!!!!

Ok, enough silliness. For the next few sentences anyway…

I’ve been using Puppet to mange systems for the last four years (at least!) however a new contract has meant I’ve needed to learn Chef. A few months ago I was looking for a blog post on the differences between puppet and Chef written from an objective point of view and the fantastic @nathenharvey produced a blog post about exactly that topic. The main take away from that blog post was that you should stop arguing about which is better and just make sure that you’re using some form of systems management tool, however there are many other good points made.

This post is more of a comment on my feelings about the two different systems and comparing the way in which they work.  Unlike Nathen, I didn’t have to make any of the WIIF decisions – the only question I had to ask was “Oh, they use Chef. Do I want a contract?” to which the answer to the second part will always override the first. I am new to Chef (I’ve been using it for a total of four hours now!) however I’m already starting to see some of the differences and I hope that this post will help others who find themselves in my position.

I’ll be running Chef in the same way I run Puppet (centralised client/server model) and I’ll try to be as subjective as I can – where I love something I’ll say so, where I think there are flaws I’ll point them out!

I’ve decided to split this down into a number of sub-sections:

  • Creating modules/cookbooks
  • Uploading modules/cookbooks to the central server
  • Applying changes to nodes
  • Registering nodes with the Server
  • Templating
  • Other stuff that doesn’t really fit anywhere else….

Creating modules and cookbooks

Chef:

knife cookbook create <cookbookname>

Puppet:

puppet-module generate myuser-mymodule

Both of these approaches create a new directory with the various sub-directories required, however puppet-module is aimed far more at collaboration with the community (the module is set up to use your puppetforge username by default) where as Chef just creates a module in the current directory for private use (although you can share these cookbooks at a later date if you so desire).

Uploading to a central server

Puppet and Chef both have the ability to run in a “standalone” mode, however it is my opinion that by doing this you remove one of the vital parts of your infrastructure – a central source of truth.

I’ll admit that I’m cheating a bit here as I’m using Hosted Chef v.s. a standard (self-installed)puppet master, however there are still a few comparisons I can draw.

When uploading to Puppet, I still recommend using something like Capistrano as the best way to get your manifests to your server, however it’s left entirely to you as the “end-user” to ensure that Puppet can see your manifests.

Chef, however, has this built in.  You just type knife cookbook upload <CookbookName> and the cookbook is on your Chef server. No messing around.

Applying changes to nodes

This is much the same between both platforms and involves a very simple command or the service running in the background.

Chef is by default verbose, Puppet is silent, however it is easy to see what puppet is doing by appending “–test” to the end of each puppet apply.

Registering nodes with the server

I’ve always used the “Autosign” feature with Puppet (restricted to a single domain and with firewall rules to ensure that only certain subnets etc. can connect to the puppet master!) so for me node registration has never been much of an issue.  The first time puppet runs, it gets a certificate and from there it works nicely.

Chef requires (as far as I can tell so far!) that the nodes are registered individually.  I see no reason why this could not be automated as part of the kickstart/pre-seed however it’s not at present something that I’ve looked into in any great depth.

Templating

This is an area that I’ve always been keen on.  The idea that /etc/my.cnf can be populated with performance tweeks automatically based upon the hardware it is installing to is awesome.

Puppet and Chef both use ERB syntax for templates and as a result I don’t believe much work would be required to port existing Puppet templates to Chef and vice-versa.

 Other stuff…

One of the things that frustrates me about Puppet is that you have to use a third-party solution to encrypt data such as passwords.  Chef has this already  in the form of encrypted databags, however I’ve yet to implement either solution.

I’m sure I’ll find more differences as I work with Chef, and I’ll try to update this post as I find them.  In the mean-time, I have to go back to Nathen’s article and agree that it doesn’t really matter if you’re using Chef or Puppet as long as you’re using something!

Source:  http://www.threedrunkensysadsonthe.net/2012/02/puppet-vs-chef-the-devops-deathmatch/

Published at DZone with permission of Matthew Macdonald-wallace, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)