8 ms·

Puppet vs Chef, Fight

145 points by bryanwb 15y ago

maratd 15y ago
> If you aren't yet using Puppet or Chef for managing your *nix infrastructure, you should seriously consider it. Why? I prefer to simply write my own bash deployment scripts. Seems easier.
- troels 15y ago
  Depends on what you mean by deployment. We use puppet for managing our os, packages and basic file structure. We use home-grown bash scripts for deploying new versions of applications. For keeping track of os-level packages and the like, I find Puppet much better than something I could build myself. It doesn't just take care of the initial setup, but also handles incremental changes. And it does so in a largely declarative language. It all guarantees that the entire installation is documented and replicable.
  - techscruggs 15y ago
    Agreed on all points. Guaranteeing the entire installation is "documented and replicable" is huge. Chef/Puppet can become a large part of you disaster recovery plan and increases the "bus number" in ops. The value in this is immediately apparent after the first time you have had to rebuild a server that you inherited.
- agj 15y ago
  I prefer bash scripting for this as well. With a small ops team, pushing for adoption of Puppet or Chef, and definitely cfengine, can be difficult. However having a backbone for running the scripts and providing reporting is a great benefit. I used slack[1] for a short while, but then started my own configuration management framework for Perl[2]. I wanted to have templating and better reporting, and also had hopes of keeping a very slim rulesest -- forcing any extraneous functions to per-instance (bash|perl|python|.*) scripts. I need to get back to developing and testing it though. 1: http://code.google.com/p/slack/ http://code.google.com/p/slack/ 2: http://search.cpan.org/~agj/Csistck-0.05/lib/Csistck.pm http://search.cpan.org/~agj/Csistck-0.05/lib/Csistck.pm
- lobster_johnson 15y ago
  I don't think you know what you're missing, actually. I recommend trying it out. In fact, you should be using Puppet or Chef even if you're just one guy with just one server to manage. The reason is that by encoding your configuration in a metalanguage such as Puppet's, you have described your environment independent of the actual box. If the box goes down and you need to swap in a new one, you just run Puppet again, and it will magically turn into the old box. If you need to replace the box with faster hardware, for example, just run Puppet on the new box, and it will (if you have done your job properly) become identical to the new one. Suddenly need 10 boxes to handle a load spike? Just boot up 10 cloud VMs and point them at the Puppet server. Since these systems are modular and lightweight, you can easily describe hundreds of vastly different boxes using a single configuration.
  - technomancy 15y ago
    > In fact, you should be using Puppet or Chef even if you're > just one guy with just one server to manage. > > If you need to replace the box with faster hardware, for > example, just run Puppet on the new box, and it will (if > you have done your job properly) become identical to the > new one. If you've done your job right with the shell script, the same will be true. The problem is that if you have more than N nodes, "doing the job right" becomes more difficult. However N is quite obviously greater than one.
techscruggs 15y ago
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. 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). 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?
- rubyrescue 15y ago
  Kevin Smith gave a talk a few weeks ago in Atlanta, that they're slowly removing those dependencies. He did specifically mention removing Couch and didn't mention Merb but based on his approach to deciding to remove Couch I'm sure he's going to address it.
  - deleted 15y ago
    [deleted]
- Woost 15y ago
  Just as a warning: If you/anyone decides to self host a chef server, you have to get the chef-server cookbook (or your couchdb will never get compacted) and you can't be running ruby 1.9.1 (or the server will have ~1 week uptime before crashing randomly) As for the core being built on merb. I don't really notice it. You'll probably never have a reason to go into the chef-server internals to change something. Besides that, it's not like it has to be serving 30k requests per second or anything. Otherwise, the Issues I've run into with chef-server: it was a little annoying to get everything installed and playing together. Couchdb + solr are very temperamental. After everything was running and stabilized(1.9.1 bad!) I've had no issues with it.
  - techscruggs 15y ago
    What version of chef server are you using? It appears to have been fixed a while again: http://tickets.opscode.com/browse/CHEF-489 http://tickets.opscode.com/browse/CHEF-489 . Perhaps your issue is not tied to your ruby version: http://tickets.opscode.com/browse/CHEF-920 http://tickets.opscode.com/browse/CHEF-920
socratic 15y ago
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. 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.) 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?
- techscruggs 15y ago
  I was a bit confused by the "excellent reference documentation" regarding Chef, as well. The documentation I have read has been out of sync, occasionally contradictory piece-meal. I have yet to find anything more useful than just reading recipes. I wonder if the author knows of resources other than that book and the wiki.
  - bryanwb 15y ago
    I have had a very different experience from yours. I have found the Chef wiki to be consistently well written and consistent. Please note that I have only been working with Chef for the past three weeks, so they may have been brought into that state quite recently.
    - techscruggs 15y ago
      That would be a great surprise! I haven't been on the wiki form ~5 months, which does make my opinion a bit dated.
  - Woost 15y ago
    The chef irc channel can be helpful (http://wiki.opscode.com/display/chef/IRC http://wiki.opscode.com/display/chef/IRC)
    - pwelch 15y ago
      I agree. What Chef lacks in documentation it makes up for it in community support. I have only been messing with Chef for a few weeks off and on but there is always someone to answer my questions in the IRC channel. Often it is someone from Opscode.
olegp 15y ago
Does anybody else think there's room for a lightweight alternative to these two projects written in server side JavaScript?
- pstuart 15y ago
  e.g., node.js + coffeescript?
- burgerbrain 15y ago
  Why should the language matter? Functionality should be the feature.
  - olegp 15y ago
    JavaScript is more widely accessible than Ruby or a DSL. So given that the point is all about creating recipes, the language is a defining feature. From what I can tell both Puppet and Chef seem a little over-engineered, so I feel there's a niche for a simple (solo only) tool out there. By using something like Node it would be possible to a) run with a much smaller memory footprint b) have a more event driven architecture and c) run multiple downloads or other setup related tasks in parallel.
    - count 15y ago
      What javascript engine ships on a linux server today? Ruby and Python are both packaged in by default on basically everything, V8 and other javascript engines are not. Additionally, javascript is NOT more widely accessible - if anything, learning non-DOM-manipulated javascript is INCREDIBLY painful for a beginner. Remember, these tools are for system administration and configuration management, not for writing applications.
      - focusaurus 15y ago
        While javascript engines are generally not shipped with OSes these days, it's moot because chef bundles its own ruby and ignores the ancient one in the OS. I suspect that's the case with python-based packages as well. I know HP Server Automation bundles its own python. It's easier to support a consistent python version across umpteen platforms than to debug your code in all the varying versions across so many distros and distro releases. Maybe Fabric can use the OS's python, but that's about the only example I know.
leoc 15y ago
How does the free version of CFEngine http://cfengine.com/ http://cfengine.com/ compare to these two?
- pwelch 15y ago
  I'm curious about this as well. Does anyone have any experience with this? It would be interesting to hear someone's opinion since CFEngine seems to have been around for awhile.
  - lusis 15y ago
    CFEngine is the "granddaddy" of configuration management. It's been around something like 17 years at this point. CFEngine spawned Puppet spawned Chef (rougly speaking) I never got involved with BCfg2 or lcfg so I don't remember the history behind.
  - Goladus 15y ago
    I have used cfengine2 extensively, but not cfengine3. I've only read about cfengine3. cfengine2 is a simple and effective mechanism for managing systems. However, cfengine2 has some issues. It has limited facilities for abstraction, resulting in a lot of code duplication. It has no built-in template engine, meaning that if you need to assemble a file based on various conditions you have to cobble it together with pattern matching and line-insertion. It's pretty easy to screw this up and lose idempotency. There's a 30-package-install limit per cfagent run, which fails silently. This is very annoying and requires some hacks to circumvent. Also, in cfengine2 you have a configuration file that's basically <classname> : <list of hosts...>. If you approach more in terms of <hostname>: <list of classes>, it's a minor inconvenience. Cfengine3 addresses some of these issues, but I haven't used it much so can't really give it a fair review.
  - deleted 15y ago
    [deleted]
  - leoc 15y ago
    CFEngine's current promise-theory-based http://en.wikipedia.org/wiki/Promise_theory http://en.wikipedia.org/wiki/Promise_theory architecture is much more recent, though.
kbd 15y ago
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?
- agj 15y ago
  It's probably the XML. Not only is Bcfg2's explicit configuration structure unpleasant to work with, the heart of it is in XML. I tried to use Bcfg2 and was easily put off by the required structure. The fact that Bcfg2 stems from the science/math community was actually the only thing that kept from overlooking it completely.
- nstielau 15y ago
  bcfg2 works well. It aims toward 100% fully managed servers (i.e. package dependency management, full /etc management) more than Chef/Puppet (but other than DoD/banking, 100% management isn't worth it). Other reasons I prefer Chef are 1) solo mode, 2) more dynamic recipes with ruby 3) more out-of-the-box resources (dirs, files, templates, users, etc)
- Goladus 15y ago
  Main reasons for me: Client-server model Insufficient online documentation for what seems to be a verbose and somewhat limited configuration language. The XML is a minor turnoff but for me it's more a question of what the language is doing. Eg: <Package name='openssh-client'/> <Package name='openssh-server'/> <Package name='emacs'/> <Package name='curl'/> <Package name='rsync'/> In puppet, you define a list of packages and then install them with one declaration or do any number of other things with that same list.
- vvpan 15y ago
  I honestly have not a single clue about Puppet or Chef, but the company I work for uses bcfg2. All of the SAs hate it with a passion. We have written so much code around it to make it usable that it could probably compare with amount of code in bcfg2 (well not really, but it's a lot).
EwanG 15y ago
AM I the only one who saw the title and assumed this was going to be the Muppet's Swedish Chef vs Emeril or someone similar?
spez 15y ago
Our experience with puppet at Hipmunk was dreadful. The configuration language is clearly designed to cause maximum pain. We have since switch to Fabric http://fabfile.org http://fabfile.org, and are much happier.
- bryanwb 15y ago
  I have written tons of fabfiles and Fabric is a great project. However it isn't intended to managed system state. It is great for code deployment but not suited to configuration management.
  - agj 15y ago
    I agree -- although I am sure you could write a system that manages config diffs, testing, backups and reporting in Fabric, it won't be pretty. My current workflow for managing systems does use Fabric however. I maintain configuration using a custom framework and work under git/hg -- Fabric tarballs the tip, syncs the tarball to several dozen servers, and then runs and my configuration module on each server. I did use a bash script previously though.
  - lobster_johnson 15y ago
    Fabric looks like a competitor to Capistrano. However, the Capistrano model is fundamentally limited and unscalable. You really don't want developers to manage application deployment. We are in the process of moving away from Capistrano to a system where code is automatically deployed when a new release is tagged. The deployment system is automatically managed with Puppet and everything is monitored with Nagios.
  - spez 15y ago
    I would argue that Puppet is also not suited to configuration management.
    - adient 15y ago
      You can argue whatever you want, but Puppet's job is to enforce system state whereas Fabric simply allows programmatic use of SSH. Fabric and Puppet are completely separate projects with very different goals.
lusis 15y ago
The correct answer to this entire question is "yes". Use whichever tool encourages you to adopt proper configuration management. 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.
- lobster_johnson 15y ago
  What do you consider to be missing in the current configuration management tools?
  - lusis 15y ago
    It's not so much what I consider to be missing as what others don't seem to be finding in them that encourages them to bolt on functionality into "incompatible" tools: http://blog.lusis.org/blog/2011/08/22/the-configuration-management-divide/ http://blog.lusis.org/blog/2011/08/22/the-configuration-mana...
pwelch 15y ago
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.
keithlard 15y ago
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: http://bitfieldconsulting.com/puppet-vs-chef http://bitfieldconsulting.com/puppet-vs-chef 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.
- lusis 15y ago
  A little while ago is a bit of a stretch. BOTH communities have moved far and beyond the state of things in that article. The fact of the matter is that X vs. Y is ENTIRELY subjective. It isn't a sporting event where there's a clear cut way to call a winner. Some people like Puppet. Some people like Chef. Anyone trying to decide between ANY software - whether two competing client libraries or something as critical as configuration management owes it to themselves and the company to try all the options. The one that's best is the one that encourages you to adopt configuration management.
rizumu 15y ago
I've been happy with Kokki and Fabric, no complaints yet: https://github.com/samuel/kokki https://github.com/samuel/kokki If I outgrow it I'll be happy to switch to chef or puppet, but it is still convenient to keep everything in Python.
viraptor 15y ago
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. 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.
moe 15y ago
I'm running both chef and puppet in production, so I will add my (slightly cynic) comparison here: 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. However, the pragmatism comes at a price: The chef-implementation is an absolute and unmitigated disaster. 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 everything is under version control and not just the parts that chef deems worth versioning). 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 very heavy on dependencies and the exact software-versions depend on when and how you install (pkgs vs source-code). 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. 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. If you care a lot about those latter minor quibbles then perhaps Puppet might be more your thing. 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. But, is it really that bad? Well. Yes. 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. So, yes, you will hate puppet every time you have to make a complex change. 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; one 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. Oh, and no least: the puppet documentation is heads and shoulders above chef (although the latter has improved recently). 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. ;-)
inopinatus 15y ago
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. 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. Turns out, packaging systems already did that and have better dependency analysis. 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. 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. Everything else they do can be replaced by a very small shell script.
- socratic 15y ago
  Can you go into a bit more detail about setting up nodes without something like Chef/Puppet? What tools do you end up using? Some sort of custom apt repository plus some shell scripts? What does it look like?
  - inopinatus 15y ago
    We have some Debian and some CentOS nodes, and yes it's an apt & yum repository. The repo itself is subdivided, debian-style, into "unstable", "testing" and "stable" which matches the states of components in our continuous delivery pipeline. So we do per-commit integration testing with "unstable", promote into acceptance & functional & regression testing (and showcases etc) with "testing" and then promote into "stable" for production. The actual promotion is done with some very small shell scripts off a CI server; the installation is managed via rundeck. The configuration packages are per-node role dependencies and we try to keep granularity large - e.g. there's a configuration package for a core Java webapp that includes the application's own resources & nginx & jetty configuration bits. For per-environment stuff (like database passwords and external integration endpoints) we just inject a (quite small) yml file to each server for the config packages to find. But configuration by convention is preferred so we also manage the DNS carefully by role (again, from rundeck) so that services are at well-known unqualified label names. Finally, the per-environment spec itself (i.e. that the rundeck scripts look at) is in a cheesy cvs tree. I keep meaning to move that to git. The base images themselves are stock virtual machine templates (AMIs for EC2 testing/dev) and the config packages & rundeck take it from there. The first step is to install a basic platform package that has lots of dependencies for our common tools, libs and needs, the the role-specific config package does the rest.
bostonvaulter2 15y ago
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?
knodi 15y ago
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. 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. If anyone here has used scalr please enlighten us of on its current state. https://scalr.net/ https://scalr.net/
atsaloli 15y ago
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): http://www.usenix.org/publications/login/2011-04/openpdfs/Lueninghoener.pdf http://www.usenix.org/publications/login/2011-04/openpdfs/Lu... and my own report from Configuration Management Summit last year: http://www.usenix.org/publications/login/2010-10/openpdfs/ConfigMgt10reports.pdf http://www.usenix.org/publications/login/2010-10/openpdfs/Co...
ajdecon 15y ago
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. 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.) 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. (edit to clarify)
jarin 15y ago
I use Puppet, but primarily because of Moonshine, a Rails plugin that ties Puppet together with Capistrano and Rake, and has a nice plugin system.
deleted 15y ago
[deleted]
Vitaly 15y ago
Puppet has runny DSL so it can do the same like in the user list example
rmoriz 15y ago
It's sad that chef differs so much depending on server/solo usage: Without chef-server using so called "chef-solo" lacks a lot of good things: + (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)) 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.

145 points by bryanwb 15y ago

> If you aren't yet using Puppet or Chef for managing your *nix infrastructure, you should seriously consider it. Why? I prefer to simply write my own bash deployment scripts. Seems easier.

troels 15y ago
Depends on what you mean by deployment. We use puppet for managing our os, packages and basic file structure. We use home-grown bash scripts for deploying new versions of applications. For keeping track of os-level packages and the like, I find Puppet much better than something I could build myself. It doesn't just take care of the initial setup, but also handles incremental changes. And it does so in a largely declarative language. It all guarantees that the entire installation is documented and replicable.
- techscruggs 15y ago
  Agreed on all points. Guaranteeing the entire installation is "documented and replicable" is huge. Chef/Puppet can become a large part of you disaster recovery plan and increases the "bus number" in ops. The value in this is immediately apparent after the first time you have had to rebuild a server that you inherited.
agj 15y ago
I prefer bash scripting for this as well. With a small ops team, pushing for adoption of Puppet or Chef, and definitely cfengine, can be difficult. However having a backbone for running the scripts and providing reporting is a great benefit. I used slack[1] for a short while, but then started my own configuration management framework for Perl[2]. I wanted to have templating and better reporting, and also had hopes of keeping a very slim rulesest -- forcing any extraneous functions to per-instance (bash|perl|python|.*) scripts. I need to get back to developing and testing it though. 1: http://code.google.com/p/slack/ http://code.google.com/p/slack/ 2: http://search.cpan.org/~agj/Csistck-0.05/lib/Csistck.pm http://search.cpan.org/~agj/Csistck-0.05/lib/Csistck.pm
lobster_johnson 15y ago
I don't think you know what you're missing, actually. I recommend trying it out. In fact, you should be using Puppet or Chef even if you're just one guy with just one server to manage. The reason is that by encoding your configuration in a metalanguage such as Puppet's, you have described your environment independent of the actual box. If the box goes down and you need to swap in a new one, you just run Puppet again, and it will magically turn into the old box. If you need to replace the box with faster hardware, for example, just run Puppet on the new box, and it will (if you have done your job properly) become identical to the new one. Suddenly need 10 boxes to handle a load spike? Just boot up 10 cloud VMs and point them at the Puppet server. Since these systems are modular and lightweight, you can easily describe hundreds of vastly different boxes using a single configuration.
- technomancy 15y ago
  > In fact, you should be using Puppet or Chef even if you're > just one guy with just one server to manage. > > If you need to replace the box with faster hardware, for > example, just run Puppet on the new box, and it will (if > you have done your job properly) become identical to the > new one. If you've done your job right with the shell script, the same will be true. The problem is that if you have more than N nodes, "doing the job right" becomes more difficult. However N is quite obviously greater than one.

techscruggs 15y ago

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. 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). 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?

rubyrescue 15y ago
Kevin Smith gave a talk a few weeks ago in Atlanta, that they're slowly removing those dependencies. He did specifically mention removing Couch and didn't mention Merb but based on his approach to deciding to remove Couch I'm sure he's going to address it.
- deleted 15y ago
  [deleted]
Woost 15y ago
Just as a warning: If you/anyone decides to self host a chef server, you have to get the chef-server cookbook (or your couchdb will never get compacted) and you can't be running ruby 1.9.1 (or the server will have ~1 week uptime before crashing randomly) As for the core being built on merb. I don't really notice it. You'll probably never have a reason to go into the chef-server internals to change something. Besides that, it's not like it has to be serving 30k requests per second or anything. Otherwise, the Issues I've run into with chef-server: it was a little annoying to get everything installed and playing together. Couchdb + solr are very temperamental. After everything was running and stabilized(1.9.1 bad!) I've had no issues with it.
- techscruggs 15y ago
  What version of chef server are you using? It appears to have been fixed a while again: http://tickets.opscode.com/browse/CHEF-489 http://tickets.opscode.com/browse/CHEF-489 . Perhaps your issue is not tied to your ruby version: http://tickets.opscode.com/browse/CHEF-920 http://tickets.opscode.com/browse/CHEF-920

socratic 15y ago

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. 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.) 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?

techscruggs 15y ago
I was a bit confused by the "excellent reference documentation" regarding Chef, as well. The documentation I have read has been out of sync, occasionally contradictory piece-meal. I have yet to find anything more useful than just reading recipes. I wonder if the author knows of resources other than that book and the wiki.
- bryanwb 15y ago
  I have had a very different experience from yours. I have found the Chef wiki to be consistently well written and consistent. Please note that I have only been working with Chef for the past three weeks, so they may have been brought into that state quite recently.
  - techscruggs 15y ago
    That would be a great surprise! I haven't been on the wiki form ~5 months, which does make my opinion a bit dated.
- Woost 15y ago
  The chef irc channel can be helpful (http://wiki.opscode.com/display/chef/IRC http://wiki.opscode.com/display/chef/IRC)
  - pwelch 15y ago
    I agree. What Chef lacks in documentation it makes up for it in community support. I have only been messing with Chef for a few weeks off and on but there is always someone to answer my questions in the IRC channel. Often it is someone from Opscode.

olegp 15y ago

Does anybody else think there's room for a lightweight alternative to these two projects written in server side JavaScript?

pstuart 15y ago
e.g., node.js + coffeescript?
burgerbrain 15y ago
Why should the language matter? Functionality should be the feature.
- olegp 15y ago
  JavaScript is more widely accessible than Ruby or a DSL. So given that the point is all about creating recipes, the language is a defining feature. From what I can tell both Puppet and Chef seem a little over-engineered, so I feel there's a niche for a simple (solo only) tool out there. By using something like Node it would be possible to a) run with a much smaller memory footprint b) have a more event driven architecture and c) run multiple downloads or other setup related tasks in parallel.
  - count 15y ago
    What javascript engine ships on a linux server today? Ruby and Python are both packaged in by default on basically everything, V8 and other javascript engines are not. Additionally, javascript is NOT more widely accessible - if anything, learning non-DOM-manipulated javascript is INCREDIBLY painful for a beginner. Remember, these tools are for system administration and configuration management, not for writing applications.
    - focusaurus 15y ago
      While javascript engines are generally not shipped with OSes these days, it's moot because chef bundles its own ruby and ignores the ancient one in the OS. I suspect that's the case with python-based packages as well. I know HP Server Automation bundles its own python. It's easier to support a consistent python version across umpteen platforms than to debug your code in all the varying versions across so many distros and distro releases. Maybe Fabric can use the OS's python, but that's about the only example I know.

leoc 15y ago

How does the free version of CFEngine http://cfengine.com/ http://cfengine.com/ compare to these two?

pwelch 15y ago
I'm curious about this as well. Does anyone have any experience with this? It would be interesting to hear someone's opinion since CFEngine seems to have been around for awhile.
- lusis 15y ago
  CFEngine is the "granddaddy" of configuration management. It's been around something like 17 years at this point. CFEngine spawned Puppet spawned Chef (rougly speaking) I never got involved with BCfg2 or lcfg so I don't remember the history behind.
- Goladus 15y ago
  I have used cfengine2 extensively, but not cfengine3. I've only read about cfengine3. cfengine2 is a simple and effective mechanism for managing systems. However, cfengine2 has some issues. It has limited facilities for abstraction, resulting in a lot of code duplication. It has no built-in template engine, meaning that if you need to assemble a file based on various conditions you have to cobble it together with pattern matching and line-insertion. It's pretty easy to screw this up and lose idempotency. There's a 30-package-install limit per cfagent run, which fails silently. This is very annoying and requires some hacks to circumvent. Also, in cfengine2 you have a configuration file that's basically <classname> : <list of hosts...>. If you approach more in terms of <hostname>: <list of classes>, it's a minor inconvenience. Cfengine3 addresses some of these issues, but I haven't used it much so can't really give it a fair review.
- deleted 15y ago
  [deleted]
- leoc 15y ago
  CFEngine's current promise-theory-based http://en.wikipedia.org/wiki/Promise_theory http://en.wikipedia.org/wiki/Promise_theory architecture is much more recent, though.

kbd 15y ago

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?

agj 15y ago
It's probably the XML. Not only is Bcfg2's explicit configuration structure unpleasant to work with, the heart of it is in XML. I tried to use Bcfg2 and was easily put off by the required structure. The fact that Bcfg2 stems from the science/math community was actually the only thing that kept from overlooking it completely.
nstielau 15y ago
bcfg2 works well. It aims toward 100% fully managed servers (i.e. package dependency management, full /etc management) more than Chef/Puppet (but other than DoD/banking, 100% management isn't worth it). Other reasons I prefer Chef are 1) solo mode, 2) more dynamic recipes with ruby 3) more out-of-the-box resources (dirs, files, templates, users, etc)
Goladus 15y ago
Main reasons for me: Client-server model Insufficient online documentation for what seems to be a verbose and somewhat limited configuration language. The XML is a minor turnoff but for me it's more a question of what the language is doing. Eg: <Package name='openssh-client'/> <Package name='openssh-server'/> <Package name='emacs'/> <Package name='curl'/> <Package name='rsync'/> In puppet, you define a list of packages and then install them with one declaration or do any number of other things with that same list.
vvpan 15y ago
I honestly have not a single clue about Puppet or Chef, but the company I work for uses bcfg2. All of the SAs hate it with a passion. We have written so much code around it to make it usable that it could probably compare with amount of code in bcfg2 (well not really, but it's a lot).

EwanG 15y ago

AM I the only one who saw the title and assumed this was going to be the Muppet's Swedish Chef vs Emeril or someone similar?

spez 15y ago

Our experience with puppet at Hipmunk was dreadful. The configuration language is clearly designed to cause maximum pain. We have since switch to Fabric http://fabfile.org http://fabfile.org, and are much happier.

bryanwb 15y ago
I have written tons of fabfiles and Fabric is a great project. However it isn't intended to managed system state. It is great for code deployment but not suited to configuration management.
- agj 15y ago
  I agree -- although I am sure you could write a system that manages config diffs, testing, backups and reporting in Fabric, it won't be pretty. My current workflow for managing systems does use Fabric however. I maintain configuration using a custom framework and work under git/hg -- Fabric tarballs the tip, syncs the tarball to several dozen servers, and then runs and my configuration module on each server. I did use a bash script previously though.
- lobster_johnson 15y ago
  Fabric looks like a competitor to Capistrano. However, the Capistrano model is fundamentally limited and unscalable. You really don't want developers to manage application deployment. We are in the process of moving away from Capistrano to a system where code is automatically deployed when a new release is tagged. The deployment system is automatically managed with Puppet and everything is monitored with Nagios.
- spez 15y ago
  I would argue that Puppet is also not suited to configuration management.
  - adient 15y ago
    You can argue whatever you want, but Puppet's job is to enforce system state whereas Fabric simply allows programmatic use of SSH. Fabric and Puppet are completely separate projects with very different goals.

lusis 15y ago

The correct answer to this entire question is "yes". Use whichever tool encourages you to adopt proper configuration management. 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.

lobster_johnson 15y ago
What do you consider to be missing in the current configuration management tools?
- lusis 15y ago
  It's not so much what I consider to be missing as what others don't seem to be finding in them that encourages them to bolt on functionality into "incompatible" tools: http://blog.lusis.org/blog/2011/08/22/the-configuration-management-divide/ http://blog.lusis.org/blog/2011/08/22/the-configuration-mana...

pwelch 15y ago

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.

keithlard 15y ago

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: http://bitfieldconsulting.com/puppet-vs-chef http://bitfieldconsulting.com/puppet-vs-chef 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.

lusis 15y ago
A little while ago is a bit of a stretch. BOTH communities have moved far and beyond the state of things in that article. The fact of the matter is that X vs. Y is ENTIRELY subjective. It isn't a sporting event where there's a clear cut way to call a winner. Some people like Puppet. Some people like Chef. Anyone trying to decide between ANY software - whether two competing client libraries or something as critical as configuration management owes it to themselves and the company to try all the options. The one that's best is the one that encourages you to adopt configuration management.

rizumu 15y ago

I've been happy with Kokki and Fabric, no complaints yet: https://github.com/samuel/kokki https://github.com/samuel/kokki If I outgrow it I'll be happy to switch to chef or puppet, but it is still convenient to keep everything in Python.

viraptor 15y ago

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. 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.

moe 15y ago

I'm running both chef and puppet in production, so I will add my (slightly cynic) comparison here: 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. However, the pragmatism comes at a price: The chef-implementation is an absolute and unmitigated disaster. 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 everything is under version control and not just the parts that chef deems worth versioning). 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 very heavy on dependencies and the exact software-versions depend on when and how you install (pkgs vs source-code). 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. 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. If you care a lot about those latter minor quibbles then perhaps Puppet might be more your thing. 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. But, is it really that bad? Well. Yes. 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. So, yes, you will hate puppet every time you have to make a complex change. 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; one 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. Oh, and no least: the puppet documentation is heads and shoulders above chef (although the latter has improved recently). 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. ;-)

inopinatus 15y ago

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. 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. Turns out, packaging systems already did that and have better dependency analysis. 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. 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. Everything else they do can be replaced by a very small shell script.

socratic 15y ago
Can you go into a bit more detail about setting up nodes without something like Chef/Puppet? What tools do you end up using? Some sort of custom apt repository plus some shell scripts? What does it look like?
- inopinatus 15y ago
  We have some Debian and some CentOS nodes, and yes it's an apt & yum repository. The repo itself is subdivided, debian-style, into "unstable", "testing" and "stable" which matches the states of components in our continuous delivery pipeline. So we do per-commit integration testing with "unstable", promote into acceptance & functional & regression testing (and showcases etc) with "testing" and then promote into "stable" for production. The actual promotion is done with some very small shell scripts off a CI server; the installation is managed via rundeck. The configuration packages are per-node role dependencies and we try to keep granularity large - e.g. there's a configuration package for a core Java webapp that includes the application's own resources & nginx & jetty configuration bits. For per-environment stuff (like database passwords and external integration endpoints) we just inject a (quite small) yml file to each server for the config packages to find. But configuration by convention is preferred so we also manage the DNS carefully by role (again, from rundeck) so that services are at well-known unqualified label names. Finally, the per-environment spec itself (i.e. that the rundeck scripts look at) is in a cheesy cvs tree. I keep meaning to move that to git. The base images themselves are stock virtual machine templates (AMIs for EC2 testing/dev) and the config packages & rundeck take it from there. The first step is to install a basic platform package that has lots of dependencies for our common tools, libs and needs, the the role-specific config package does the rest.

bostonvaulter2 15y ago

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?

knodi 15y ago

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. 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. If anyone here has used scalr please enlighten us of on its current state. https://scalr.net/ https://scalr.net/

atsaloli 15y ago

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): http://www.usenix.org/publications/login/2011-04/openpdfs/Lueninghoener.pdf http://www.usenix.org/publications/login/2011-04/openpdfs/Lu... and my own report from Configuration Management Summit last year: http://www.usenix.org/publications/login/2010-10/openpdfs/ConfigMgt10reports.pdf http://www.usenix.org/publications/login/2010-10/openpdfs/Co...

ajdecon 15y ago

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. 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.) 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. (edit to clarify)

jarin 15y ago

I use Puppet, but primarily because of Moonshine, a Rails plugin that ties Puppet together with Capistrano and Rake, and has a nice plugin system.

deleted 15y ago

[deleted]

Vitaly 15y ago

Puppet has runny DSL so it can do the same like in the user list example

rmoriz 15y ago

It's sad that chef differs so much depending on server/solo usage: Without chef-server using so called "chef-solo" lacks a lot of good things: + (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)) 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.