I am currently migrating a largish (thousands of nodes) site away from using Chef and back to using config files in packages, because it's simpler and has the same effect.<p>Having been round the houses with cfengine, Chef, Puppet and more now I think these tools are, overall, a poor use of time. In general they're 99% used as config blasters: Yet Another Way To Put Files Onto A Computer.<p>Turns out, packaging systems already did that and have better dependency analysis.<p>This also helps to match the lifecycle of configuration management objects with that of the components they configure. I've seen far too many sites that had one big hairball of a Chef/Puppet repository that tried to service the needs of multiple conflicting application releases.<p>The final nail in the Chef coffin is that it encourages parameterisation of config files rather than configuration by convention, which is simpler and less prone to production-environment gotchas.<p>Everything else they do can be replaced by a very small shell script.
Our experience with puppet at Hipmunk was dreadful. The configuration language is clearly designed to cause maximum pain.<p>We have since switch to Fabric <a href="http://fabfile.org" rel="nofollow">http://fabfile.org</a>, and are much happier.
I use Chef, but without the server (chef-solo). I have a hard time stomaching the idea of dealing with a Merb application (an abandoned framework) that has some rather complex dependencies (couchdb & rabbitmq). That being said, plenty of peers have told me that they have not experienced any problems with running a Chef server.<p>Maybe this means I should just fork up the cash for hosted Chef, but I don't see it as a 100$ a month value (I currently have 10 nodes and treat them all as ephemeral).<p>I do wonder why this is never brought up. Is it not seen as a red flag to anyone else that the core of Chef is built on Merb?
Am I totally missing some obvious Chef documentation? The entirety of the documentation when I last looked seemed to be the wiki + the one 50-page O'Reilly book.<p>I ended up literally printing out the wiki. (And the wiki seemed to be in a state of pretty extreme flux and/or disagreement with what blog posts suggested was best practice.)<p>The business model of the companies promoting Puppet and Chef seems to be to charge for support and/or hosted services. Which is fine. But is it leading to abysmal documentation?
Something that wasn't visible in the article: Not that Puppet is extremely better here, but I really hate how much manual tweaking Chef requires after installing from a package and the experience in running it needed. You cannot easily scale it (indexed database pretty much needs to stay in one place), couchdb stops replication at random and it seems that chef doesn't deal well with document versioning in general since I keep running into a situation where the cookbook is not on the list after uploading, or a visible cookbook cannot be deleted. It also sometimes requires reindexing for some unknown reason, or the attributes don't work properly in search.<p>I prefer to work with Chef much more than Puppet (as a user/developer), but I wouldn't want to be responsible for running Chef cluster itself. There are too many different elements to learn and take care of. Unfortunately official hosted service is very expensive, so there's no good alternative once you need many nodes.
I'm running both chef and puppet in production, so I will add my (slightly cynic) comparison here:<p>When comparing Chef to puppet then Chef comes out as the pragmatist. Once up and running most common every-day tasks are less painful in chef. Apart from that its main advantage over puppet (to me) is that it allows to semi-sanely manage transient hosts (cloud/EC2) that enter/exit a cluster ad hoc. Puppet can also do that in theory, in practice you'd rather want to fork your eyes out with a spoon.<p>However, the pragmatism comes at a price: The chef-implementation is an absolute and unmitigated disaster.<p>You'll spend quite a bit of quality time initially to get the six dozen components to play ball and to fix up basics that shouldn't need fixing (i.e. you'll want to ensure that <i>everything</i> is under version control and not just the parts that chef deems worth versioning).<p>Over the first couple months you'll also see the odd server-crash while you figure out the peculiarities of your particular installation. Chef is <i>very</i> heavy on dependencies and the exact software-versions depend on when and how you install (pkgs vs source-code).<p>However, once you're over that hump and if you're not too worried about standing on the shoulders of 'a one-eyed amongst the blind' then the whole cookbooks/roles/runlists arrangement is quite comfortable to work with.<p>Just don't expect features like dry-run, real idempotency or clean dependency tracking that some would consider "basic" for such a tool. Also don't expect a security-model at all; to my knowledge all hosts that are authorized to talk to a chef-server can see all cookbooks and databags on that server.<p>If you care a lot about those latter minor quibbles then perhaps Puppet might be more your thing.<p>Puppet is conceptually much cleaner (night/day difference), which sadly and ironically is also its biggest drawback; they took it too far. Puppet made a bad decision early on by inventing their own language. This decision will be your personal ball on a chain for the lifetime of your puppet deployment.<p>But, is it really that bad?
Well. Yes.<p>After the initial (steep) learning curve there's only a small plateau of reward before you begin to run into the more subtle issues. The most commonly heard complaints about the language are the ass-backwards class/variable-inheritance and the blurry (and effectively undocumented) divide between what should go into the manifests (sorta like chefs "cookbooks") and what into a storage layer called "extdata" (sorta somewhat like chefs "databags"). But rest assured, there's plenty more, I don't want to spoil it all at once here.<p>So, yes, you <i>will</i> hate puppet every time you have to make a complex change.<p>Yet for some it might still be worth it, here's some of my reasons: Once you finally have something up and running puppet feels much more predictable and "solid" than chef. You can actually dry-run and test (most) changes before rolling them out. Puppet will provide meaningful error messages in most situations (unlike the esoteric chef stack-traces). The puppet daemon is just that; <i>one</i> daemon (unlike the conglomerate of moving parts that comprises a chef deployment). Generally speaking there is much less "magic" in puppet than in chef. You will almost always know precisely what went wrong - a pretty important attribute that chef unfortunately doesn't share.<p>Oh, and no least: the puppet documentation is heads and shoulders above chef (although the latter has improved recently).<p>So, if you're in the market, good luck making your choice. I'm not making a recommendation here because, quite frankly, I wouldn't recommend either to anyone other than my worst enemy. ;-)
The correct answer to this entire question is "yes". Use whichever tool encourages you to adopt proper configuration management.<p>Yes, there's a gap that the current crop of CM tools don't address (and why we see new versions of capistrano clones with a bit of system management sprinkled in) but the three major tools right now - Puppet, Chef and CFengine are all at a state where they address 95% of the use cases for system management and automation.
A little while ago I wrote a piece comparing Puppet vs Chef on 10 different criteria and concluded that Puppet wins on all of them: <a href="http://bitfieldconsulting.com/puppet-vs-chef" rel="nofollow">http://bitfieldconsulting.com/puppet-vs-chef</a><p>It stimulated a very interesting discussion in comments in which some of the leading lights from both communities (and there is some overlap) took part.
This is a good write up. As someone who just recently started messing with Chef I found comparison articles non-existent. Though I have already put in several weeks with Chef and will probably stick with it I think Puppet looks like a great product as well. I hope both of these projects continue to gain users. It would be great to see them both compete/innovate well into the future. With that said I would like to see Chef's documentation increase and the merb application replaced by something else as someone else suggested. In the end they are both great tools and if you are sys admin it wouldn't hurt to learn one really well and become familiar with the other just like working with different Linux distros such as RHEL/Ubuntu only increases your sys admin skills.
I've been happy with Kokki and Fabric, no complaints yet: <a href="https://github.com/samuel/kokki" rel="nofollow">https://github.com/samuel/kokki</a> If I outgrow it I'll be happy to switch to chef or puppet, but it is still convenient to keep everything in Python.
While I often see "Puppet vs Chef", I never see Bcfg2 mentioned. Is its low mindshare related to its quality, it's exclusion from the set of Ruby-based config management tools, its origin in the government space, or its terrible name?
This article came at an excellent time: I've recently been setting up test deployments of both Puppet and Chef for potential HPC use, and this article confirms a lot of my impressions. In particular, that Puppet has much better documentation (especially for doing the initial setup) and a more sysadmin-friendly language, but that Chef makes it easier to carry out complex tasks.<p>Despite some cool things I've been able to do in Chef, Puppet is probably going to end up the winner, if for no other reason than it having much much better support for RHEL and clones (ie Scientific Linux). Chef was extremely unimpressive there in many ways, and anything related to deployment where the wiki includes the line "RPM installation via ELFF has been deprecated" is going to be a non-starter in the HPC world. (Or doesn't, anymore... any mention of RPM seems to have been scrubbed now.)<p>We're probably only going to use it on infrastructure/head nodes though: our compute nodes are provisioned on ramdisk statelessly using Warewulf, and are easier to reconfigure with a reboot/redeploy than via CM.<p>(edit to clarify)
It's sad that chef differs so much depending on server/solo usage:<p>Without chef-server using so called "chef-solo" lacks a lot of good things:<p><pre><code> + (remote) bootstrapping + distribution (like "little-chef"; non-official)
+ data bags (third party cookbook only; non-official)
+ search (e.g. on a central file system based data-base which gets dumped into a json that will be uploaded on bootstrap/update time (push))
</code></pre>
As others stated, running your own chef-server (even external/paying for it) brings a new risc factor into your provisioning business and if you depend on data bags and search you'll most likely not be able to bootstrap new app servers when your chef server is down. This is a huge SPOF.
For those getting started with Configuration Management, I would recommmend "Getting Started with Configuration Management" by Cory Lueninghoener (in April 2011 issue of USENIX ;login: magazine): <a href="http://www.usenix.org/publications/login/2011-04/openpdfs/Lueninghoener.pdf" rel="nofollow">http://www.usenix.org/publications/login/2011-04/openpdfs/Lu...</a><p>and my own report from Configuration Management Summit last year: <a href="http://www.usenix.org/publications/login/2010-10/openpdfs/ConfigMgt10reports.pdf" rel="nofollow">http://www.usenix.org/publications/login/2010-10/openpdfs/Co...</a>
I haven't used Puppet but I have had the misfortune of using Chef (1k+ node deployment). But for a free alternative its not bad, it gets the job done sure we'll have to sacrifice or work around it but in the end you can do what you need to do with it. Yes, its not RightScale but thats why RightScale is not free.<p>I haven't tried out scalr my self but I hear it described as an alternative to RightScale with 90% of the features at 10% of the cost.<p>If anyone here has used scalr please enlighten us of on its current state.<p><a href="https://scalr.net/" rel="nofollow">https://scalr.net/</a>
> If you aren't yet using Puppet or Chef for managing your *nix infrastructure, you should seriously consider it.<p>Why? I prefer to simply write my own bash deployment scripts. Seems easier.
I've been using puppet recently, one thing I wish for is an easier way to pull in other puppet's users modules. I've looked at puppetforge some but I balk at actually downloading the files to run locally. Is chef better in this regard?