Hacker News new | comments | show | ask | jobs | submit login

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

I (with advice from co-workers) decided against chef for two main reasons: Dependencies and complexity of implementation, and gut instinct from reading the literature. So I'm not surprised to see that it can be a little shaky.

I also looked at cfengine3, and I liked the language, although I am not a fan of the "promise/promiser" terminology, the concept is consistently applied and as a result the language grammar is much simpler than puppet's. It basically came down to not being able to really choose between puppet and cfengine3 without actually trying them, and since I cared less about identifying the optimal tool than just getting stuff done I selected puppet arbitrarily.

I rejected bcfg2 mainly because it seemed very server-oriented and although there was documentation for setting up the system there wasn't a lot of documentation about how to actually configure systems. I've revisited bcfg2 lately and the situation doesn't seem to have improved much. (eg I can't find a decent reference for the configuration language anywhere online. There's no equivalent to that puppet page that lists all the data types.) I also think the choice for XML as the configuration language is suboptimal but I could probably work with it.

So we went with puppet, and although I left the position several months later (for unrelated reasons) we were already hitting some of those issues you mentioned.

Incidentally, you don't even need the daemon to run puppet, so long as you're willing apply your own security model and distribution method (rsync over ssh, etc/).

From a complete outsider's point of view, it sounds as if the state of the art SCM tools are at the pre-2005 level of VCS tools. Chef and Puppet are the SCM equivalents of CVS or Subversion. The Git/Mercurial equivalents (in terms of power) have yet to appear. Does this analogy make sense?

Not bad but rather awkward I think. Source control is a comparatively specific problem. System configuration management is a much broader category, and competes indirectly with a variety of existing tools, like fabric or even make and bash.

It makes sense to me. I thought "we're waiting for the git(hub) of SCM" before I saw your post.

I have no real experience with configuration management, but I'm confused why the programming language matters?

It seems to me like people complaining about Make being a poor programming language.... IT'S NOT FOR PROGRAMMING! It's for build sequencing. Every single program on your computer is a command-line-invocation away. Let Make handle incrementally executing external scripts based on timestamps, and let real programming languages do what they do best.

Isn't the point of Puppet to have an idempotent declarative language. And can't it execute arbitrary programs?

Isn't the point of Puppet to have an idempotent declarative language. And can't it execute arbitrary programs?

Yes and no. The main argument against puppet's dedicated DSL is that it's dedicated. I.e. you'll spend a lot of time learning a complex language for the sole purpose of running puppet. You cannot transfer that knowledge to anything else and unless managing puppet is your only job you'll frequently have to re-read the documentation to recall the more exotic idiosyncrasies.

It's a love/hate-thing really. In puppet you can express many things much more cleanly and elegantly than in chef. Other things you can't express at all or require you to resort to terrible hacks.

In chef-cookbooks you rarely need to resort to hacks. But at the cost of the chef-infrastructure itself being a pretty terrible hack...

Curiosity, not to be argumentative:

What are some examples of things are really elegant to express in Puppet? What are some examples of things that you had to resort to terrible hacks for?

Please use personal, concrete examples, if you don't mind.

I've only got a couple of boxes to manage, but reading through the docs for the big three configuration management systems, I really was confused about the need for most of the stuff in the tutorials. I'd also be interested in concrete examples of where shell-scripts fail so badly.

Well, it's of course all subjective, but I can present my perception of both (elegance vs hack) in a single pastie: http://pastie.org/2668110

This will assemble a hosts-file that contains all hosts from $group, on the hosts that include the class.

It's awesome and terrible at the same time because it demonstrates an Exported Resource (@@host, Host <<| |>>, awesome) and at the same time it shows how we had to resort to extdata for grouping (extlookup = terrible) and how opaque the puppet DSL is to the uninitiated.

I have no idea how to begin to read that...

How is this better than something like this:

    gen-hosts config-file > /etc/hosts

See this gist I just made: https://gist.github.com/1274379

That script is (1) more understandable to a programmer, (2) unambiguous with respect to output, (3) idempotent, (4) super extensible.

I suspect your Puppet script is doing some other stuff, but I can't begin to mentally parse it...

EDIT: Just wanted to point out that I didn't try to make that script either correct or identical to your script. Just wanted to give an impression of the flow of things.

Well, scripts like yours go a long a way. The problem is that at some point you'll want more integration and at that point you can either go with puppet/chef - or you'll end up re-inventing them.

More integration with what?

What would I be reinventing?

Again, I'm genuinely ignorant in this department. Really curious what I'm not understanding, but I just get the feeling that "worse is better" here.

I'm interested to know why someone would not recommend CM (or atleast not recommend puppet/chef). I think despite its faults, I've seen that many problems become non-issues when you are using puppet. OTOH, I've seen organizations struggle for months(or for ever) with what could have been a simple solution with puppet.

Could it be you made the wrong design decisions both times? Sometimes, people try to do complex things in puppet, when they should using puppet just to push out that cronjob or init script, or rpm/apt package to handle the complexity.

Can you give more details like how many serves you have? Do you have a complex combination of hardware(physical + virtual) and operating system platforms?

Do you have a complex combination of apps on these platforms? Did you use the "environments" feature of puppet/chef? (Environments are totally broken in puppet) Did you use Dashboard/Foreman or Grill(chef only) and did that make things easier?

Did you migrate from the "hairball nest of Bash and Perl that holds your data center together" or did you build your infra from scratch with puppet/chef?

not recommend CM

Sorry, that part was irony. I would of course recommend CM. I was just trying to express that the current crop of tools is nowhere near a level of maturity where you could recommend one or the other as a no-brainer.

Could it be you made the wrong design decisions both times?

Surely. More so with puppet than with chef as the puppet language offers slightly more rope to hang yourself on the foot. However, I'm quite confident we have maxed out both tools to about the best of their abilities now (short of the more esoteric extensions such as mcollective). There is of course always a next step, but I can't think of something that could potentially change my perception of their respective problem areas (which, as I outlined in my parent post, are pretty fundamental for each tool).

Can you give more details like how many serves you have?

Largest puppet deployment is ~70 hosts, largest chef is ~40 hosts.

Yes, we've had to migrate the puppetmaster to a pretty beefy host. Yes, chef's claim to scalability is a joke. We experimented with couch replication but quickly went back to running separate (beefy) chef-servers and sync'ing them via git.

A tangential reason for running separate puppetmaster/chef instances is the lack of a trustworthy security model in both. Extdata/databags do occasionally contain sensitive information, neither puppet nor chef accounts for that (don't get me started on "encrypted databags").

Do you have a complex combination of hardware(physical + virtual) and operating system platforms?

We run (only) debian on physical and cloud servers. For cloud deployments chef works better for us. For physical servers we're rooted in puppet but slowly leaning towards chef for uniformity. I wouldn't say our deployments are especially complex. And even if they were then that'd be no excuse for the tools that were created to manage precisely that kind of complexity.

Did you migrate from the "hairball nest of Bash and Perl that holds your data center together" or did you build your infra from scratch with puppet/chef?

The bigger clusters were built from scratch but we have chef/puppet clusters in various states of finesse.

Oh, this reminds me of one of the less obvious issues that I forgot in my initial rant: Updates.

You absolutely, positively want to either update your entire cluster (all puppet/chef clients) in lockstep with the server or not at all. The "backwards compatibility"-claims didn't work out for us when we tried.

Moe, my takeaway from this was.... roll your own :)

In all seriousness (kinda), many thanks for the great write up on the current state of provisioning tools.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact