Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Puppet vs Chef, Fight

devopsanywhere.blogspot.com

Post reply on HN
Print view View original

91–100 of 109 posts

Re: Puppet vs Chef, Fight

#91

Post by atsaloli »

esessoms wrote: post #44
leoc wrote: 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 genera…

I've been working on improving getting-started information for CFEngine 3. Check out www.verticalsysadmin.com/cfengine.htm - especially the "Getting Started with CFEngine 3" guide, and the "Guide to CFEngine Body of Knowledge".

I also hold live webinars to help people get started with CFEngine 3. If you need any help, I invite you to register for one (http://cfengine-quickstart.eventbrite.com/)

Re: Puppet vs Chef, Fight

#92

Post by atsaloli »

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

and my own report from Configuration Management Summit last year: http://www.usenix.org/publications/login/2010-10/openpdfs/Co...

Re: Puppet vs Chef, Fight

#93

Post by olegp »

burgerbrain wrote: post #89
olegp wrote: post #85

Earlier quoted context omitted.

Chef, Puppet and configuration management systems in general aren't as widely used or known as one would think. So yes, I'd argue that using a more widely accessible language is relevant. I agree that JavaScript isn't the only way to achieve this. It's just that JavaScript is a language I like, so I thought I'd find out if there were others who shared my views. Perhaps I should have expanded more on things in my firs…

I'm confused, are you proposing using Javascript instead of a DSL with a system like Chef or Puppet? That's a separate issue from what the system itself is written in... The downvoting is probably over confusion, shared by myself, about what the language used to write the system itself has to do with the merits of the system.

Chef uses Ruby for recipes, I propose using JavaScript. If the system itself was written in JavaScript, then writing recipes in it would allow for more flexibility.

(EDIT: perhaps having the ability to define recipes using a JSON only format would work as well)

Re: Puppet vs Chef, Fight

#94

Post by ajdecon »

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)

Re: Puppet vs Chef, Fight

#95

Post by grandalf »

inopinatus wrote: post #83
socratic wrote: post #68

Earlier quoted context omitted.

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?

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 "stabl…

Very interesting comments. I have lately been trying to choose between puppet and chef and I think I had a hunch that there was a better/cleaner way.

What do you recommend for managing the running state of processes, etc?

Re: Puppet vs Chef, Fight

#96

Post by jarin »

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.

Re: Puppet vs Chef, Fight

#97

Post by inopinatus »

grandalf wrote: post #95
inopinatus wrote: post #83

Earlier quoted context omitted.

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 "stabl…

Very interesting comments. I have lately been trying to choose between puppet and chef and I think I had a hunch that there was a better/cleaner way. What do you recommend for managing the running state of processes, etc?

I prefer to use whatever's native to the platform. On Debian that means start-stop-daemon; on CentOS the init.d functions.

It's a whole "my house, my rules" strategy. If you play nice with the underlying platform, it'll play nice with you. The downside is that you do have two packaging models to build for. I know that abstracting this is one of the motivations for Chef et al. I have yet to see a usage where this was worth the opportunity cost.

Re: Puppet vs Chef, Fight

#98

Post by munchhausen »

dredmorbius wrote: post #57
nigelk wrote: post #30

Earlier quoted context omitted.

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

Nigel, that's an excellent move. The one persistent thread I've seen with "support-based models", notably Red Hat, is that ... the tools leave you requiring support, and yet the support still sucks (in large part because the support engineers have to use the same crappy tools you do). I'm not going to pretend I've got the Free Software business model sorted out. But I have noticed that project goals and incentives do…

> From an ease-of-use / ease-of-maintenance perspective, Debian (and its derivatives) blow RPM-based systems out of the water.

What kind of a comparison (Debian vs. RPM-based) is this? Does dpkg(1), as opposed to rpm(8), really make all the difference in "ease-of-use"?

Of course, I understand what you mean, however, don't you think that if Debian really blew RHEL and SLES out of the water, its adoption in the enterprise server space would be a bit higher? You are kidding yourself if you pretend that the commercial distros are only used because they come with support, and also need support, being intentionally crippled.

Obviously, a meaningful comparison of Debian, RHEL and SLES does not fit into a HN comment, but as someone who has used all three, I would always choose Debian last, and not only because of the lack of commercial support.

(By the way, the main point of the support you get for RHEL and SLES is not access to a guy on the phone. The real value is the L3 support, i.e. bugfixing. As a Debian user who runs into a bug that cripples your system, your options are:

a) fix it yourself

b) pray to $DEITY that Debian developers fix it soon

c) try to expedite b) by harassing Debian developers in bugzilla, which is going to be as inefficient as you'd expect.

As a paying customer of Red Hat or SuSE, you are entitled to and will receive a fix for the bug ASAP, and although ASAP often translates to "a couple of weeks", it is still a hell of a lot better than what Debian can offer.)

Re: Puppet vs Chef, Fight

#99

Post by Joakal »

spez wrote: 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.

Puppet/Chef/Cfengine are different to Fabric/Capistrano

The former are pull management, eg nodes request configuration. The latter are push management, eg main server pushes to nodes.

My main concern is that you did not point out your requirements. So you leaped from one technology to a different one because puppet was 'maximum pain'.

Re: Puppet vs Chef, Fight

#100

Post by moe »

snprbob86 wrote: post #81
moe wrote: post #79

Earlier quoted context omitted.

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

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

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.
Post reply on HN