I'm curious which tool is generally preferred for infrastructure management: Puppet or Chef?
Here's a rough unofficial analysis of high level points.
Puppet
- Older product
- Stronger community than Chef
- Significant number of community modules https://github.com/search?q=puppet (1947) at current count http://forge.puppetlabs.com/
- Written in Ruby but requires a Ruby DSL to really use the language.
Chef
- Newer product
- Less community support and activity.
- Less number of community modules https://github.com/search?q=chef (1498) at current count (newer product so to be expected ... they've achieved greater growth faster than puppet. chef is half as old as puppet.) http://community.opscode.com/cookbooks
- native ruby
What I've been able to figure out is that puppet is pure awesome 9 out of 10 times but when you hit a complex scenario it starts to get weird and complicated. I've heard people mention that you tend to have many Chef users that have migrated from Puppet because of shortcomings with these more complex scenarios while Chef users tend to be able to solve those problems. I just hit what I think is one of these scenarios by trying to build a pure nginx/php when I wanted to use the ppa at https://launchpad.net/~nginx/+archive/php5 .. Puppet has choked pretty well when it comes down to the timing of when it is pulling from a repo vs updating sources. I'm about to switch over to Chef to see if I can create the same build without the issues I hit in Puppet. Would be fantastic if anyone has previous experience that could help guide me.
Comments
Have you tried posting your problem on puppet-users mailing list
They have a ton of experienced folks there, including folks at puppetlabs. I suspect your issues may be easily resolvable with the addition of mcollective into the mix.
Cheers,
Brian
Also #puppet
The IRC channel is a good source of community help.
Chef * Less community support
I would disagree with this. In fact, I usually argue the opposite.
Opscode started out by publishing a large number of cookbooks that the community has contributed to and extended:
https://github.com/opscode/cookbooks
Broken up version here:
https://github.com/cookbooks
The great thing about chef cookbooks is, you can start with an existing one and only override what you need. It's very much like Drupal theming that way. If I have opscode's apache2 cookbook in /cookbooks, I can make an apache2 directory in /site-cookbooks and it can contain only one template file, which will override the template in the parent cookbook. If I need to define more variables, I can add my own attributes.rb (kinda like a preprocess function) that will get merged with the parent's.
This has allowed me to put together configurations very quickly with little custom code. You may be seeing fewer chef projects on github because that community is better about duplication. For example, I've received contributions for almost all of the cookbooks I maintain:
https://github.com/msonnabaum/chef-phpunit
https://github.com/msonnabaum/chef-drush
https://github.com/msonnabaum/chef-xhprof
Here's an example of how you'd handle that PPA in chef:
apt_repository "nginx-php-ppa" do
uri "http://ppa.launchpad.net/nginx/php5/ubuntu"
components ["main"]
keyserver "keyserver.ubuntu.com"
key "C300EE8C"
action :add
notifies :run, "execute[apt-get update]", :immediately
end
package "php5"
Chef will be smart enough to update from that ppa before it installs the package.
Community support != cookbooks
Disclaimer - I am a Puppet Labs employee. But I was a Puppet customer for a few years before I joined up, and I made my own Puppet vs. Chef evaluation and decided to go with Puppet at that time.
Please don't confuse community support with cookbooks. Cookbooks are awesome, and it's great that people contribute them, but community support is more about actually understanding what your tool is going to do in large and divergent environments. The more adopters you have and the more people involved in the community, the more likely that the tool you use is going to get eyes on your weird corner case situation before you hit it.
-Eric
While I not 100% certain
While I not 100% certain about what issues cyberswat is having, it is fairly straightforward to install from a ppa in puppet as well: http://stackoverflow.com/questions/7209489/how-to-work-with-puppet-depen... using puppet's "require" dependency method, with notify or subscribe to define the relationship.
Puppet can *seem* harder
Because what you're trying to describe with Puppet is how your server is going to look, not the procedure for making your server get to that state. That's not how we're often trained to think, and it can make reasoning out how to write the code tricky at first.
The benefit you get long-term from doing this, however, is that your code remains accurate and current even if the procedure changes. We typically say "you worry about the what, Puppet worries about the how" - that's not strictly true since you can tell Puppet "how" as well, but even in that case the definition of "how" is abstracted and separated away from the "what." In the long term this doesn't just lead to maintainable code - it leads to a maintainable environment.
Don't think of Puppet as a programming language - think of it as a model for describing systems.
Can you clarify further about what problems you're running into with Puppet and that PPA? Maybe we can help.
-Eric
You should be able to do this
You should be able to do this in puppet by using run stages.
Just make sure the run stage setting up the PPA and updating the sources runs
eg. stage { nginx_ppa: before => Stage['main'] }
I spent some more time
I spent some more time digging into this and also attempted the same build in chef. I wasn't to worried about the specific problem I outlined as much as I was interested in choosing the best platform. I found the chef documentation to be significantly better than the puppet documentation but I found puppet significantly easier for me to use than chef. I spent one weekend on each build and while I got up and running easier with chef initially, I found that I made significantly more progress with puppet. FWIW the run stages were the golden ticket for puppet. Thanks for the feedback!
even found a way to get past
even found a way to get past my specific problem without relying on the latest puppet version if any are interested https://github.com/cyberswat/puppet ... This builds php5.3/php-fpm/nginx on Ubuntu 10.04
+1 housesroom
Sounds like the Puppet Docs need help for the Drupal community and for ISP's?
Sense?
Jeremy Donson
Database and Systems Engineer
New York City
Just add a third option here,
Just add a third option here, I've been watching Saltstack lately and have found it to be moving very quickly.
I haven't actually been able to get it up and running yet though I did manage to install it on Ubuntu and Fedora.
www.saltstack.org
It is python based and uses zeromq.
I am all about best tool for the job....
You can add any other choices, but we ought to develop GREAT criteria.
Generally the trade-offs regard convenience vs required complexity...
Jeremy Donson
Database and Systems Engineer
New York City
NYC: Jan 12 and March 8 presos on Chef and Puppet.
NYLUG (New York Linux Users Group) will be hosting talks from both Opscode (Chef) and Puppetlabs (Puppet) and on Jan 12th and Mar 8th respectively. You can RSVP for both talks here: http://www.meetup.com/nylug-meetings/ (Right now, you can only RSVP for the January event, but you will be able to RSVP for the Puppet talk at some point in February).
These WILL NOT be Drupal specific talks, but should give folks a good sense of both systems.
@brandorr mind if we cross
@brandorr mind if we cross post those meetups here as events?
Don't mind...
Feel free, however since I posted the link, the Chef talk is fully RSVPed and we are on a waiting list now. I'm hoping to get good news on getting more spots opened up though so signing up for the waiting list is encouraged. Looking for someone to take video of the meeting though in case we still have more interest than seats..
ENTHUSIASTIC +1 FOR CHEF!
Just wanted to chime in: At Myplanet Digital, we started playing around in the config management space pretty much as developers interested in exploring a bit. I checked out both Chef and Puppet and Chef just made more sense. In retrospect, one of the main perks with learning chef was that it became a launch pad for learning ruby, since it uses an internal DSL. This basically just means the DSL is built with the actual language, and not using some custom parser. Since tons of amazing devops and testing tools are written in ruby, it really gave me a leg up to start exploring everything else that was available.
Learning chef = learning ruby = gateway drug to devops.
And since part of the reason for using config management was to make it so that everyone could get their hands into the stuff that's configuring servers and local environments (without mucking around directly on machines), it means that everyone on the team is getting more familiar with ruby. Overall, Chef just seems like a sysadmin tool for developers, while Puppet always looked like a sysadmin tool for sysadmins. Not sure where I heard that originally, but it really rings true for me now.
So yeah, we chose Chef, and never looked back. Not a one regret.
conclusion?
@cyberswat: just curious, after your experiences and months later ... are you now using either Chef or Puppet exclusively?