55

I already googled and read the "to-puppet-or-to-chef-that-is-the-question" article.

I'm interested in use cases, real world implementations in which people had choosen one or the other on real problems bases.

I'm particularly interested in integration with cobbler issues ( I know puppet is much a standard approach in this direction ); as anybody any experience in cobbler-chef integration ?

Thanks in advance

drAlberT
  • 10,871
  • 7
  • 38
  • 52
  • related: http://serverfault.com/questions/42565/floss-server-management-and-audit-tools – warren Dec 22 '09 at 19:27
  • 1
    @warren: the post you outline is not related. I'm asking for a direct comparison between this tools, not just a mention of chef as it was done in the post. – drAlberT Dec 25 '09 at 17:15
  • To answer the cobbler+chef question I have a branch in my cobbler checkout to return JSON for Chef to use, but I don't have a system to test it. Let me know if you're interested in testing. – jtimberman Aug 18 '10 at 07:00
  • Of course, but I can't right now... I'm going to continue my tests in some months, something else got priority right now – drAlberT Aug 18 '10 at 07:47
  • Regarding the closure of the question .. I asked for "real problems", cobbler-integration, uses-cases ... not simply "opinions", but motivated choices. I'm against the closure, as you can argue :) – drAlberT Oct 24 '13 at 09:27

6 Answers6

62

To be honest, I think this comes down to simple viewpoint: Chef seems more of an imperative, programmatic solution, the usage of ruby as the language instantly makes me hope somebody ported it to python, as is the way of the world with all of ruby's ideas.

That's not what you want for this sort of thing though. You want to speak to the void where the system will be and declare:

"Upon port 80 summon from the north the daemon named nginx. His task is to serve."

"A user should exist, his name should be chiggsy and he should be one of the mighty in the group of wheel,"

"Raise up a wall of fire, thin in the places 80,443,8080"

And so on, although perhaps in language less flowery.

Puppet supports that paradigm better IMO. I'd have used either one, I had no preference but when it came down to it, declarative suited me better.

Puppet.

chiggsy
  • 1,576
  • 1
  • 15
  • 20
  • 2
    You could even go one step further in future and use Linux distribution that uses declarative configuration: http://nixos.org/nixos/ – iElectric Oct 16 '13 at 09:16
18

I've written a detailed comparison of Chef vs Puppet here: Puppet vs Chef: 10 reasons why Puppet wins. Although it doesn't include use cases, I hope it provides some useful starting points for people wondering which tool to choose for their infrastructure automation.

John Arundel
  • 539
  • 3
  • 4
  • 3
    Very good work. Even if many of the point you wrote are bound to the simple fact that puppet is "older", and so much more "supported". Ok, it is a fact ... but I think that none would ever had used postfix becouse sendmail had already a great public... I repeat, good work, I'll take it into account – drAlberT Jan 16 '10 at 16:14
  • AlberT - yes, Puppet has been around longer than Chef and so has many of the first-mover advantages: code maturity, developer base, installed base, mindshare - these are explicitly acknowledged in the article. Is Puppet technically superior to Chef for Linux automation tasks? Probably not. I still recommend Puppet versus Chef because it's the market leading configuration management tool. – John Arundel Jan 26 '10 at 14:15
  • 2
    The blog article is very outdated, as of 2011 puppet now supports pure ruby modules, and also has many more 'verbs' than the version that the author evaluated. – robbyt Mar 20 '11 at 03:06
14

Sorry about the verbosity. Use the tool that makes it's easy to get your job done. That's the point of automation, right?

History: I have used puppet in past gigs and last month I spent about a week trying to get used to chef to see if I would make the switch at my new gig.

I didn't leap.

Jargon: One unfortunate problem with both of these systems is the jargon overload. (recipes, templates, nodes, roles, attributes, providers) It goes on and on. I found Chef took it a step farther. (Knife, Shef, etc.)

Code Maturity: Suffice to say that I found Chef just a little too raw. It feels a lot like what puppet felt like in the .21/.22 timeframe 3-4 years ago. There's a lot of flux going on.

Not to say that hasn't happened in puppet either. (I re-discovered many great features in puppet that have only surfaced in the last few years. -- regex matching!)

Ruby: I didn't like all the ruby overload in Chef. (you need gem and rake before you can even get started) You can use ruby to solve complex problems in puppet a'la facter, but you don't have to if you don't want to.

Complexity: I didn't like the GUI focus on chef. I realize it's pretty and the puppet has a web interface in the works as an add on, but I feel that should be more decoupled.

Chef has a much more complex architecture. It might scale better, but there are lots of potential points of failure.
http://wiki.opscode.com/display/chef/Architecture

Chef needs couchdb, rabbitmq and solr in addition to the API server and web interface.

I just want a simple client/server interface that doesn't need a MVC framework on top of it and a complex data store behind it.

Puppet is a lot simpler in that department. (not to say there aren't lots of add ons to make it messier)

Getting work done: In the end, I went with what I knew. After spending a week of side hacking and barely being able to get basics done with Chef, I was able to go back to puppet and pound out my basic needs in a few hours. (package management, user management, config file templates)

Caveat about Modules: Puppet has a recent shift to using "modules" which are contributed by third parties. I didn't end up using these and I found a wide range in their quality. Be sure to peek under the covers and see what and how they are working before you dig in to these.

Joel K
  • 5,765
  • 2
  • 29
  • 34
5

Here is a opinion: We have tried all of them in our company and we prefere puppet. Simply because it is easy to use.

Riaan
  • 411
  • 5
  • 13
  • Have you used any front-end for monitoring Puppet execution? – SyRenity Dec 28 '09 at 20:57
  • 1
    @syrenity we use a custom nagios check that checks the mtime of $puppetvardir/state/state.yaml which only gets updated on a successful run. – rodjek Dec 28 '09 at 21:08
  • 2
    Is chef so difficult instead? Why? What is practical difficulties encountered approaching chef that puppet bypass? – drAlberT Jan 04 '10 at 09:26
  • 1
    http://theforeman.org/wiki/foreman/Screenshots – Not Now Mar 17 '10 at 01:44
  • @NotNow: nice, I'd adopted for sure if it would support cobbler integration as an alternative to its own provisioning system ... – drAlberT Dec 06 '10 at 10:02
  • @AlberT: The provisioning part in Foreman is optional. We use Cobbler and Foreman independently. We want to move to Foremans provisioning, because IMO, it is much superior to Cobblers. And much, much faster when you have 100s of servers. – Not Now Dec 27 '10 at 20:35
1

I myself have seen cases where managing 1000 hosts with different configs, is much easier with puppet. Infact companies like google uses puppet for their deployment.

The main design architecture of puppet is such that, it works much better than others if you configure it in the right way. For example adding your custom facts for your custom configs etc. the below links might provide some info http://slashroot.in/puppet-tutorial-installing-puppet-master-and-puppet-agent

http://slashroot.in/puppet-tutorial-how-does-puppet-work

sarath
  • 11
  • 1
0

This may have changed since last time I tried it, but when I was trying chef on RHEL there was no clear way to install it. Someone had created a yum repo that had all packages needed, but it ended up installing 200 odd packages. Puppet on the other hand has a single rpm (and a couple of dependencies).

Noodles
  • 1,356
  • 3
  • 18
  • 29