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

81–90 of 109 posts

Re: Puppet vs Chef, Fight

#81

Post by snprbob86 »

moe wrote: post #79
snprbob86 wrote: post #73

Earlier quoted context omitted.

Curiosity, not to be argumentative: What are some examples of things are really elegant to express in Puppet? What are some examples of things that you had to resort to terrible hacks for? Please use personal, concrete examples, if you don't mind. I've only got a couple of boxes to manage, but reading through the docs for the big three configuration management systems, I really was confused about the need for most of…

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

EDIT: Just wanted to point out that I didn't try to make that script either correct or identical to your script. Just wanted to give an impression of the flow of things.

Re: Puppet vs Chef, Fight

#82

Post by adient »

spez wrote: post #70
bryanwb wrote: post #24

Earlier quoted context omitted.

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.

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.

Re: Puppet vs Chef, Fight

#83

Post by inopinatus »

socratic wrote: post #68
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?

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 "stable" for production. The actual promotion is done with some very small shell scripts off a CI server; the installation is managed via rundeck.

The configuration packages are per-node role dependencies and we try to keep granularity large - e.g. there's a configuration package for a core Java webapp that includes the application's own resources & nginx & jetty configuration bits.

For per-environment stuff (like database passwords and external integration endpoints) we just inject a (quite small) yml file to each server for the config packages to find. But configuration by convention is preferred so we also manage the DNS carefully by role (again, from rundeck) so that services are at well-known unqualified label names.

Finally, the per-environment spec itself (i.e. that the rundeck scripts look at) is in a cheesy cvs tree. I keep meaning to move that to git.

The base images themselves are stock virtual machine templates (AMIs for EC2 testing/dev) and the config packages & rundeck take it from there. The first step is to install a basic platform package that has lots of dependencies for our common tools, libs and needs, the the role-specific config package does the rest.

Re: Puppet vs Chef, Fight

#84

Post by Goladus »

reinhardt wrote: post #72
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…

From a complete outsider's point of view, it sounds as if the state of the art SCM tools are at the pre-2005 level of VCS tools. Chef and Puppet are the SCM equivalents of CVS or Subversion. The Git/Mercurial equivalents (in terms of power) have yet to appear. Does this analogy make sense?

Not bad but rather awkward I think. Source control is a comparatively specific problem. System configuration management is a much broader category, and competes indirectly with a variety of existing tools, like fabric or even make and bash.

Re: Puppet vs Chef, Fight

#85

Post by olegp »

burgerbrain wrote: post #32
olegp wrote: post #23

Earlier quoted context omitted.

JavaScript is more widely accessible than Ruby or a DSL. So given that the point is all about creating recipes, the language is a defining feature. From what I can tell both Puppet and Chef seem a little over-engineered, so I feel there's a niche for a simple (solo only) tool out there. By using something like Node it would be possible to a) run with a much smaller memory footprint b) have a more event driven archite…

Unless chef and puppet are having a hard time finding developers, I don't see how javascript being more accessible is relevant. Your point about them being over engineered is much more interesting than you just thinking we need yet another system but in a different language. And javascript is certainly not the only way to achieve the goals you list. Just seems like an attempt to start a language war honestly.

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 first comment. That being said, I'm pretty surprised by the negativity in the comments and downvoting.

Re: Puppet vs Chef, Fight

#86

Post by knodi »

I haven't used Puppet but I have had the misfortune of using Chef (1k+ node deployment). But for a free alternative its not bad, it gets the job done sure we'll have to sacrifice or work around it but in the end you can do what you need to do with it. Yes, its not RightScale but thats why RightScale is not free.

I haven't tried out scalr my self but I hear it described as an alternative to RightScale with 90% of the features at 10% of the cost.

If anyone here has used scalr please enlighten us of on its current state.

https://scalr.net/

Re: Puppet vs Chef, Fight

#87

Post by blantonl »

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…

Moe, my takeaway from this was.... roll your own :)

In all seriousness (kinda), many thanks for the great write up on the current state of provisioning tools.

Re: Puppet vs Chef, Fight

#88

Post by [deleted] »

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…

[deleted]

Re: Puppet vs Chef, Fight

#89

Post by burgerbrain »

olegp wrote: post #85
burgerbrain wrote: post #32

Earlier quoted context omitted.

Unless chef and puppet are having a hard time finding developers, I don't see how javascript being more accessible is relevant. Your point about them being over engineered is much more interesting than you just thinking we need yet another system but in a different language. And javascript is certainly not the only way to achieve the goals you list. Just seems like an attempt to start a language war honestly.

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.

Re: Puppet vs Chef, Fight

#90

Post by mattdeboard »

adient wrote: post #82
spez wrote: post #70

Earlier quoted context omitted.

I would argue that Puppet is also not suited to configuration management.

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.

Post reply on HN