Live data from Hacker News

Puppet vs Chef, Fight

devopsanywhere.blogspot.com

41–50 of 109 posts

Re: Puppet vs Chef, Fight

#41
post #24
post #18

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 , and are much happier.

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.

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.

Re: Puppet vs Chef, Fight

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

Re: Puppet vs Chef, Fight

#43
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

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.

Re: Puppet vs Chef, Fight

#44
post #8

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

CFEngine has really great, comprehensive, reference documentation and really very poor, basically non-existent, tutorial or getting-started information. In order to actually get work done, you need to know a good bit more than how to install it and what the bundle syntax looks like. Puppet OTOH excels in this.

So while the tools are roughly equivalent in capability, if you're new to configuration management in general I think you'll have a lot better success getting started with Puppet.

Re: Puppet vs Chef, Fight

#45
post #30
post #5

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 charg…

"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?" This is one of the reasons we're moving Puppet Labs from being a support company to a product company, and not for hosted services. If your bread and butter comes in from support, you have no incentive to actually make your product easier…

It's gotten better, but it still is very messy.

What it needs above everything else is a table contents that stays with you as you read. The documentation you have now only lists a TOC for the section you're in. And the TOC is tucked away in the right-hand corner and stays there when you scroll. So whenever I dive into your docs, I never get a sense of "where" I am in the whole big ball of string, and I get frustrated.

The first page is weirdly arranged. For example, it's got a big headline "Learning Puppet", then "Learn to use Puppet! New users: start here." Then there is a link to "Introduction and Index". I interpret this as being the link to the "new users" guide, and that the next two sections ("Part one", "Part two") are not related. But if you click on "Introduction and Index" you come to a new page which lists the exact same TOC, and has no section named "Introducion". It's confusing.

The "reference manual" and "guides" sections are similarly confusing because of the lack of a unified table of contents. The reference is particularly bad because I want to look up something alphabetically ("I want to manage users, so I bet it's called 'user'"), but the reference is arranged by topic.

Re: Puppet vs Chef, Fight

#46
post #7

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

There's always room to reimplement X in your favourite programming language.

It might start as a lightweight rival and yet it will continue to grow in the same trajectory as its rival eventually.

I would recommend more people to read, analyze, and understand the history and nature of software.

Re: Puppet vs Chef, Fight

#48
post #7

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

Puppet is quite lightweight, and since Puppet configs are written in a DSL, the language shouldn't matter. Please don't reinvent the wheel just because server-side JS is cool right now.

Re: Puppet vs Chef, Fight

#49
post #39
post #8

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

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.

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.

Re: Puppet vs Chef, Fight

#50
post #2

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

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.

Post reply on HN