Live data from Hacker News

Puppet vs Chef, Fight

devopsanywhere.blogspot.com

1–10 of 109 posts

Re: Puppet vs Chef, Fight

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

Re: Puppet vs Chef, Fight

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

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.

Re: Puppet vs Chef, Fight

#4
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?

Re: Puppet vs Chef, Fight

#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 charge for support and/or hosted services. Which is fine. But is it leading to abysmal documentation?

Re: Puppet vs Chef, Fight

#6
post #3
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.

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

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.

Re: Puppet vs Chef, Fight

#9
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…

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.

Post reply on HN