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

101–109 of 109 posts

Re: Puppet vs Chef, Fight

#101

Post by kokey »

atsaloli wrote: post #91
esessoms wrote: post #44

Earlier quoted context omitted.

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/ )

I'm grateful for your shameless self promotion. Your guide is certainly more engaging than the official tutorial.

Re: Puppet vs Chef, Fight

#102

Post by adient »

mattdeboard wrote: post #90
adient wrote: post #82

Earlier quoted context omitted.

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.

I've written loads of fabfiles and a subclass of Task a few times. I've also wrestled with Puppet and Chef and been resoundly defeated by both. Fabric does what we need it to do for now for provisioning & deployment. And frankly you can make it do whatever you want. "Programmatic use of SSH" isn't something to be scoffed at; it's simple yes but it also lets you do whatever the hell you want very simply.

Yes, of course. Nothing is wrong with using Fabric. It's a clear step above trying to use shell scripts to manage your servers and deployments. But what I am seeing across several comments is that tools like Puppet and Chef are clearly misunderstood by many developers. As a sysadmin myself, I would say that there is definitely a larger picture to the use of Puppet/Chef than what developers are looking for, and thus something like Fabric is much more suitable.

Re: Puppet vs Chef, Fight

#103

Post by vvpan »

kbd wrote: post #16

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?

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

Re: Puppet vs Chef, Fight

#106

Post by rmoriz »

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.

Re: Puppet vs Chef, Fight

#107

Post by grandalf »

inopinatus wrote: post #97
grandalf wrote: post #95

Earlier quoted context omitted.

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…

Interesting. Thoughts on upstart? BTW do you use anything along the lines of nagios, god, monit, etc.?

Re: Puppet vs Chef, Fight

#108

Post by atsaloli »

kokey wrote: post #101
atsaloli wrote: post #91

Earlier quoted context omitted.

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/ )

I'm grateful for your shameless self promotion. Your guide is certainly more engaging than the official tutorial.

Thank you for the positive feedback.

And I'll try to tone my next post better so it comes across as eager rather than shameless.

Yours truly, Aleksey

Re: Puppet vs Chef, Fight

#109

Post by snprbob86 »

moe wrote: post #100
snprbob86 wrote: post #81

Earlier quoted context omitted.

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.

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.

Post reply on HN