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

61–70 of 109 posts

Re: Puppet vs Chef, Fight

#61

Post by snprbob86 »

moe wrote: post #59

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

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?

Re: Puppet vs Chef, Fight

#62

Post by inopinatus »

I am currently migrating a largish (thousands of nodes) site away from using Chef and back to using config files in packages, because it's simpler and has the same effect.

Having been round the houses with cfengine, Chef, Puppet and more now I think these tools are, overall, a poor use of time. In general they're 99% used as config blasters: Yet Another Way To Put Files Onto A Computer.

Turns out, packaging systems already did that and have better dependency analysis.

This also helps to match the lifecycle of configuration management objects with that of the components they configure. I've seen far too many sites that had one big hairball of a Chef/Puppet repository that tried to service the needs of multiple conflicting application releases.

The final nail in the Chef coffin is that it encourages parameterisation of config files rather than configuration by convention, which is simpler and less prone to production-environment gotchas.

Everything else they do can be replaced by a very small shell script.

Re: Puppet vs Chef, Fight

#64

Post by technomancy »

inopinatus wrote: post #62

I am currently migrating a largish (thousands of nodes) site away from using Chef and back to using config files in packages, because it's simpler and has the same effect. Having been round the houses with cfengine, Chef, Puppet and more now I think these tools are, overall, a poor use of time. In general they're 99% used as config blasters: Yet Another Way To Put Files Onto A Computer. Turns out, packaging systems a…

> Turns out, packaging systems already did that and have better dependency analysis.

The one thing that keeps me from wanting to switch entirely to apt for deployment is its insane insistence that multiple versions of the same package may not be installed at once. This is (usually) fine for user-level stuff, but there are lots of legitimate reasons to want to keep multiple versions installed in a deployment situation.

Re: Puppet vs Chef, Fight

#65

Post by moe »

snprbob86 wrote: post #61
moe wrote: post #59

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

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

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

Re: Puppet vs Chef, Fight

#66

Post by bostonvaulter2 »

I've been using puppet recently, one thing I wish for is an easier way to pull in other puppet's users modules. I've looked at puppetforge some but I balk at actually downloading the files to run locally. Is chef better in this regard?

Re: Puppet vs Chef, Fight

#67

Post by technomancy »

lobster_johnson wrote: post #50
maratd wrote: 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,…

> In fact, you should be using Puppet or Chef even if you're > just one guy with just one server to manage. > > 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.

If you've done your job right with the shell script, the same will be true. The problem is that if you have more than N nodes, "doing the job right" becomes more difficult. However N is quite obviously greater than one.

Re: Puppet vs Chef, Fight

#68

Post by socratic »

inopinatus wrote: post #62

I am currently migrating a largish (thousands of nodes) site away from using Chef and back to using config files in packages, because it's simpler and has the same effect. Having been round the houses with cfengine, Chef, Puppet and more now I think these tools are, overall, a poor use of time. In general they're 99% used as config blasters: Yet Another Way To Put Files Onto A Computer. Turns out, packaging systems a…

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?

Re: Puppet vs Chef, Fight

#69

Post by Goladus »

moe wrote: post #59

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

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

Re: Puppet vs Chef, Fight

#70

Post by spez »

bryanwb wrote: post #24
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.

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.

I would argue that Puppet is also not suited to configuration management.
Post reply on HN