Review: Puppet Vs. Chef Vs. Ansible Vs. Salt

snydeq writes "InfoWorld's Paul Venezia provides an in-depth review of Puppet, Chef, Ansible, and Salt — four leading configuration management and orchestration tools, each of which takes a different path to server automation. 'Puppet, Chef, Ansible, and Salt were all built with that very goal in mind: to make it much easier to configure and maintain dozens, hundreds, or even thousands of servers. That's not to say that smaller shops won't benefit from these tools, as automation and orchestration generally make life easier in an infrastructure of any size. I looked at each of these four tools in depth, explored their design and function, and determined that, while some scored higher than others, there's a place for each to fit in, depending on the goals of the deployment. Here, I summarize my findings.'"

Comments

Oh really?

[mybeat]

"That's not to say that smaller shops won't benefit from these tools"
I call BS on that statement, I run puppet at home for my 2.5 servers, it really simplifies my life.

Re:Oh really?

[Joining Yet Again]

In English, unlike many other languages, a double negative means a positive (sarcasm aside). The guy is agreeing with you.

Re:Oh really?

[mybeat]

Thanks for pointing that. And yes, English isn't my native language

Re:Oh really?

[Anonymous Coward]

unlike many other languages

Citation please. I think for that kind of sentence virtually every language can translate word by word to mean exactly same thing?

Re:Oh really?

[Joining Yet Again]

Look up "negative concord".

Re:Oh really?

[ivano]

Italian: "non ho fatto niente" means "I didn't do anything", but a literal translation is "I didn't do nothing". So some languages allow you to use a double negative to signify the negative.

Re:Oh really?

[XaXXon]

whoooosh!

Re:Oh really?

[higuita]

At least im East-Timor, when you ask something in a negative question ( "will not meet today?"), they usually reply directly to the question ("yes, we will not meet"), instead of the more usual negative confirmation ("no, we will not meet").

If the above example is already a little confusing, when you get a single "yes" or "no" reply, you are totally lost on what was really the reply... and learn very quickly that you must not ask negative questions if you really need a reply!! :)

for sure there are many other places were the same kind of think/talk exists

Re:Oh really?

[Anonymous Coward]

(sarcasm aside)

- Joining Yet Again on Friday November 22, 2013 @10:39AM

Will that do as a citation?

Re:Oh really?

[somersault]

That's the same in English.. negative questions cause confusion :p when someone answers yes or no, you either have to gather the meaning from the context and tone of voice, or ask for clarification.

Re:Oh really?

[3.5 stripes]

Ma sei sicuro? Io ti ho visto girando la intorno.

Re:Oh really?

[Sique]

In English, you can also have sentences where a double negative puts more weight on the negation. ("I haven't seen no negation.")

Standard-German for instance always interprets a double negative as positive, quite different from some German dialects.

Re:Oh really?

[Anonymous Coward]

Sometimes there are more than two logic states. Somebody will create a clever sequence of sentences but here's an example:

A) There is fog today

NOT A) There is no fog today.

NOT NOT A) There isn't no-fog today.

Fog (A), sun (B), rain (C), snow (D), etc?

Re:Oh really?

[ruir]

Not only Italian, but other latin languages too like Portuguese. In fact, we have to make a deliberate effort in order not to use double negatives in English.

Re:Oh really?

[Anonymous Coward]

la` with the accent, paisa'

Re:Oh really?

[umghhh]

that confirms my experience in all languages that I know well enough (that would be 3.5) - high language (as high German) tends to be correct logically whereas the low and/or less formal language is allowing for freedom of expression and letting you deduce the meaning of say double negation (by using the context usually). I would even go as far as to claim that if a language is big enough (big enough meaning: number of speakers, universities and literature also scientific etc) it develops into different dialects one of which is high language where negation is formally what it is i.e. if you negate things twice you just made a full turn (something that some claim is a 180degrees turn.....).

I think all the trouble we have with expressing our thought and understanding them come from how inadequate any language is - I think Goedle did have some funny ideas on this.

Re:Oh really?

[3.5 stripes]

Lo so, ma il mio tastiera e' inglese, e sono troppo pigro di cercare la mappatura giusta. (lo so, si mancano anche in questo )

Re:Oh really?

[hab136]

http://en.wikipedia.org/wiki/Double_negative#Slavic_languages

In Slavic languages other than Slavonic, multiple negatives are grammatically correct ways to express negation, and a single negative is often incorrect [...] For example, in Serbian, Niko nikada nigde nita nije uradio ("Nobody never did not do nothing nowhere") means "Nobody has ever done anything, anywhere", and Nisam tamo nikad ila ("Never I did not go there") means "I have never been there".

CFEngine

[Anonymous Coward]

...is still my tool of choice.

Re:CFEngine

[Anonymous Coward]

CFEngine3 is what Puppet would've been if Luke knew what he was doing, rather than "I'm gonna take my ball and go play somewhere else" as a reponse to not having his dumb ideas integrated into CFEngine2. And Chef is just Puppet for people who can't understand how declarative languages work. "ZOMG, I need everything to happen in a precise sequence, because the concept of convergent policy is so hard to grasp," Chef users all say in unison.

Have I mentioned how irritating it is that Puppet resource types are defined in lower-case, but have an upper-case letter when they're dependencies? And how the "sometimes we put a semicolon after a statement, sometimes there's a comma, and everything has its own format" really shows the inexperience that Luke had when designing the language? The CFEngine3 language is extremely consistent. And honestly, the learning curve is not that much higher. Never mindthe atrocious performance of all these things doesn't come close to compiled CFEngine3. Try to recursively set or verify permissions on a directory containing, say, >30K files. I'll see you in a few hours with Puppet. Or in a few seconds with CFEngine. I haven't tested that with the other tools (saltstack is irrelevant in searching for convergence, though). Of course, why would anyone expect to manage permissions on more than a couple thousand files with a config management tool?

summary

[Joining Yet Again]

Since these are all cookie-cutter solutions for a broad range of necessarily very different scenarios, your choice will depend on how well your scenario fits in with the features provided by each product.

As always, the ideal solution will come from rolling your own, possibly by heavily customising an existing solution - which may include one of these. But you may not have the knowledge or the time to do this, and it might piss off corporate if they would rather something which makes you easily replaceable. The correct solution here is to document, but it's a rare sysadmin who is both a good coder and a good documenter too.

Re:summary

[Anonymous Coward]

The odds of successfully rolling your own package management and deployment solution is challenging enough to even talented specialists, and then you expect documentation?

But sure, that's the ideal solution. I presume the problem starts out, "first, assume a spherical sysadmin in a frictionless environment..."

Re:summary

[Joining Yet Again]

These products merely provide hooks into native package management.

Re:summary

[gbjbaanb]

If you expect documentation, and probably support too, then you will find a commercial package (eg Landscape) will fit your needs better than the free equivalents.

That's not to say the commercial equivalent is better in any way, or necessarily does more, or has better features.. just that they are the ones to go with if you need that level of support.

Or you could just hire someone to provide you with that support internally, the fat sysadmin that was mentioned :)

Re:summary

[Anonymous Coward]

Completely wrong. That's only single function of a large tasklist that these tools are used for. Anything an administrator could want to do on a server can be automated via these programs. Configuration updates, custom software installation, version controlled code distribution, directory and file permission sanity checks and so on. The list is endless.

It's *how* these application go about performing these jobs and how complicated it is to write the script / recipe / yaml file to perform the task that is the main difference along with any agent software that needs to be installed.

Re:summary

[Anonymous Coward]

Yes, hooking into package management is certainly one thing they do do very well. I can have a puppet snippet like:

package {
    'firefox': ensure => 'latest';
    'rails': ensure => '4.0.1', provider => 'gem';
    'textminer': ensure => 'latest', provider => 'pip';
}

and run that same script on multiple Linux distributions with the same effect (for packages with different names on different distros, there is a way to abstract the package name).

But, that is not all puppet can do. Look up the Puppet Type Reference for a complete list of the kinds of resources puppet can manage, but here's a few:

user {
    'root': password => 'some password hash';
    'ac': ensure => 'absent';
    'jya': ensure => 'present', comment => 'Joining Yet Again', shell => '/bin/zsh';
}

interface {
    'FastEthernet0/1': ensure => 'shutdown';
    'FastEthernet0/2': ensure => 'no_shutdown', allowed_trunk_vlans => '5,10,20', encapsulation => 'dot1q';
}

zfspool {
    'pool1': ensure => 'present', mirror => ["disk1 disk2", "disk3 disk4"];

The most important feature of tools like puppet and cfengine (which are the two I use) that is not evident by looking at the snippets is *idempotency*. When running, the frameworks abstract the process of comparing the current state of the system to the desired state and only performing the necessary actions to move the system closer to the desired state; a well written script can be run repeatedly without harm.

Even if the package management was merely all the tools provided, it would be worth it. Instead of:

Am I running on a Debian derivative?
        Y: use_apt
Am I running on a Red Hat derivative?
        Y: use_yum
Am I running on an unknown derivative?
        die

Is firefox package installed?
        N: install using apt or yum
        Y: Is installed firefox package the latest available?
                N: update using apt or yum
                Y: do nothing

write:

package { 'firefox': ensure => 'latest' }

Re:summary

[CrankyFool]

I can't possibly disagree with you more.

When I joined my current company about four years ago, we were running a home-grown configuration management system. When I argued against this with the sysadmin who had built it, he handwaved about "those other, much too complicated, CMSs," and "this one does exactly what we want."

Only it didn't. It resulted in customers using phrases like "we asked for eight webservers and we got eight webservers all of which were almost exactly alike." Almost.

I know, I know, we all think we're smart and talented and it's easier for us to simply roll something out than figure out how to adapt Chef, Puppet, etc to our environment. We're wrong. There's tremendous value to using a standardized tool and, honestly, if I have to bet on some random schmoe coming up with a good fullfeatured less-buggy idempotent (etc etc etc) configuration management system or Chef or Puppet being able to do it ... I'll go for the thing that has been out for a while, is supported by a vibrant community, and is used on thousands of servers already. Everything else is just misplaced arrogance.

Re:summary

[Bigbutt]

The problem on my side is we have a lot of legacy gear including Tru64 and old HP-UX 11.0.0 boxes that run critical applications. New systems are being rolled out on virtual systems for non-critical applications. I have a lot of scripts I write but they're for information gathering mostly.

I've looked at various tools like cfengine when I got here 6 years ago and more recently things like Puppet and Chef but find they aren't really built to solve my problem and many have clients that go on the systems or other software (Ruby, Python?) where the systems don't support it (the Tru64 systems for instance).

Since the scripts do what I need to do and since we're a pretty diverse environment, it doesn't seem to be a good idea to deploy something like Puppet on a subset of systems and maintain scripts on the others thereby increasing the complexity of the environment.

I am still on the lookout though and these articles are helpful (well except that all the ads crash my browser so I can't read the full article). I'm interested in Ansible because it requires no agent.

[John]

Re:summary

[visualight]

I don't know, people have been doing large scale deployments and management huge groups of servers since forever. Long before puppet was an idea people were deploying thousands of completely identical servers in minutes. It's really not that hard.

That said, of the four in the review, I'm in favor of salt. I have previously considered chef and puppet and rejected them as not worth my time. There's no "win" over doing it the way it's always been done (by people who actually know something). Salt is different, there's actually a benefit to people at every level of experience. Maturity aside, it takes a superior approach in my opinion and it's the best bet for long term investment.

Re: summary

[Anonymous Coward]

How the hell are these all cookie cutter?

Most of my experience is with Puppet, and aside from the cron resource, everything was built (in Puppet) in-house. Our environment is 500ish servers, and a couple dozen in-house modules. We started writing custom functions now, and those are straight Ruby. Very little of what we do is actually OS configuration, and even of that, almost nothing is out-of-the-can.

We even have a pattern for doing custom package management with zip files, but I'm sure most people do, for tomcat, or java installs, or.. RPM just sucks for too many uses folks, sorry if I offend a purist but it's true.
In pseudo code...
file {"hidden thepackage.zip location":
        source => file server,
} ->
exec {"extract package":
        command => "unzip -d thedestination thepackage.zip",
        creates => "thedestination"
}
exec {"post install script":
        command => "do something to thedestination",
        refreshonly => true,
        subscribe => Exec["extract package"],
  OR maybe
        creates => "thedestination/aflagfileonsuccess",
}

I'm sure that's very common, but I'm demonstrating idempotence with the exec resource which let's you do _anything_. Nearly everything that is not in a system package and init.d gets done that way, and that's a LOT of stuff.

In any real world environment with these tools, you will ALWAYS still be writing custom scripts (or 'worse' if you adopt mcollective too), the difference is they will be written for these tools, and with idempotence, like using flag files.

Re:summary

[Joining Yet Again]

It sounds like either your sysadmin wasn't good enough or you overestimate the capabilities of puppet &co. The only way to get two servers exactly the same is to buy same hardware from the same batches then image the drives.

My experience with these tools is that they work "well enough", giving you reasonably similar configurations across servers... providing you have fairly routine needs on mainstream platforms. But there are SO MANY niggly differences between platforms and builds that almost all your work is going to go into identifying and accommodating for those differences. For security-conscious deployments, in particular, you want to do nothing less than study each individual platform's quirks.

A senior sysadmin will have been maintaining automation tools for longer than most of the tools mentioned in this article have existed. The problem is not the guy who has built and maintained a working system, but the upstart who whines that he actually has to learn something new and won't get a new buzzword to put on his CV. If your in-house system isn't 100% perfect, don't use that as an excuse to throw the baby out with the bathwater. If you're building something from scratch, DO evaluate ALL these options, but be prepared to have to consider EVERYTHING they do behind the scenes in order to understand whether they're behaving exactly as you want them to.

Lastly - and this advice for puppet users in particular - try not to get a hard-on for the word "idempotence". It's not that complex or unique a concept.

Re:summary

[Joining Yet Again]

Context of GP, goddammit. As far as package management, these tools do not provide package managers, merely hooks into native package management.

Re: summary

[Joining Yet Again]

And what do you regard as the complex part of puppet itself here?

Re: summary

[Anonymous Coward]

I'm sure that's very common, but I'm demonstrating idempotence with the exec resource which let's you do _anything_.

I've got a TARDIS I'd like to sell you.

Re:summary

[aesiamun]

The reviews were of the Enterprise versions. Puppet and Chef Enterprise is far from free...

Re: summary

[Anonymous Coward]

I've got a TARDIS I'd like to sell you.

Bring it round last week, and I'll make you an offer.

Re:summary

[Anonymous Coward]

> Lastly - and this advice for puppet users in particular - try not to get a hard-on for the word "idempotence". It's not that complex or unique a concept.

Ha - for sure - its not like MAKE has been doing the same thing since the v7 days, and just as easily can be automated via a single NFS share to
manage a whole farm identically, repeatably, and tracably (the last when combined with version control)

Re:summary

[Anonymous Coward]

Whereas CFEgine enterprise is free for up to 25 nodes. :)

Re: summary

[Anonymous Coward]

And what do you regard as the complex part of puppet itself here?

Doing that on 500 hosts in parallel each time an update goes out, in a declarative language, with a dependancy tree instead of "script foo died on line X on Y servers, good luck figuring out what state they are now in"

Really, a declarative tree of configuration points, It's running scripts in some steps but It's so much more.

Re: summary

[Joining Yet Again]

in a declarative language, with a dependancy tree

I have a manpage here dated 15 August 1978 - guess what it's for.

Re:summary

[Anonymous Coward]

I agree with you to some extent. But then we have the exceptions, like Linux itself, or git, or many other examples where some bright fellow(s) thought she/he/they could do it at least as well themselves. And they were right.

That's how we got Puppet, Chef, Ansible, and Salt in the first place. They all thought they could do it better in some way. And now you're saying it's unlikely that you could do it better than them.

Look how many alternatives there are to ec2 now. Can somebody do it better than openstack? Well, probably. Would it take some smarts and a lot of work? Yes. Would it be worth it? Well, if it was better than ec2 and openstack and eucalyptus and all the established players... then yes. That would be cool.

Can somebody build a better Nagios/OpenNMS. Probably not in a single afternoon. But it can be done.

It can't be done by everyone, or just anyone. But it can be done. It gets done all the time. And we're all glad of that.

I've seen institutions burn through millions of dollars over a decade on failed SAP/Peoplesoft/Oracle replacements of homegrown systems. Imagine if they had spent the time, money, and other resources on blooming their custom system.

Sometimes it is best to work together to improve a project. Linus could have done that with SVN. Instead, he did something completely different. Is it better than Mercurial? Would Mercurial be better if Linus had spent his efforts there? Maybe; maybe not. But I think that SVN and Mercurial are both better because of git. Puppet is better because of Ansible. Javascript is better because of Ruby.

I'm glad that a lot of people work together to improve Linux. But I'm also glad that other people are going different ways with OpenBSD. Luckily, there's plenty of people in both pursuits and they haven't fractured into 10 million MyOses. And who knows what that freak over in the corner working on NoReallyThisIsGoingToBeCool OS might come up with.

Oh yeah. And Go Hyperloop!

Another one...

[Anonymous Coward]

When i evaluated this tools i just did one thing:

Checked job offers that quoted those tools.

Answer:

Go for Chef / Puppet, because you will never find people with the other ones skills.

Between Chef and Puppet, it's pretty much a question of taste / existing skills in your company.

Re:Another one...

[Joining Yet Again]

Whyyyyyyyyyyyyy are people employed on the basis of skill with specific ephemeral brands.

You want their brains, not their.. oh never mind. This is why I am out of the software business.

Re:Another one...

[Boltronics]

Go for Chef / Puppet, because you will never find people with the other ones skills.

My workplace uses Salt. Just saying.

Re:Another one...

[amalcolm]

Exactly oh for mod points!

Re:Another one...

[higuita]

Go for Chef / Puppet, because you will never find people with the other ones skills.

you know, skills are learned, not born with.... you people with a little brain and dedication will learn whatever skill its needed

Re:Another one...

[goddidit]

Whyyyyyyyyyyyyy are people employed on the basis of skill with specific ephemeral brands.

You want their brains, not their.. oh never mind. This is why I am out of the software business.

Measuring brains is hard. For example, phrenology gives only a crude estimate.

Re:Another one...

[Joining Yet Again]

You are right that phrenology, IQ tests, generic aptitude tests, etc. are inappropriate measures of ability.

But actually taking time to look at what went into fulfillling particular qualifications, experience, hobbies is relevant and very possible. Relevant technical interviews which test general engineering skills and probationary periods are also valuable.

Re:Another one...

[gbjbaanb]

that's because they don't want you to learn the transferable skills that make you attractive to other employers. Just saying :)

Re:Another one...

[Thanshin]

Because some people are ephemeral too.

If I want to hire someone I'll be firing in a year, I couldn't care less about his skills other than exactly what I want him to do during that year.

Re:Another one...

[Joining Yet Again]

I wouldn't describe "number of years you've dablled in [package]" as a skill. I've dabbled in loads of things for 20+ years, but it says very little about my skill with them. What is more, anyone who sees "10+ years experience with [package]" is going to edit their CV to emphasise their experience with [package].

OTOH, I am quite competent with tools I've spent far less time with, because I've had to apply my skills to producing clever shit.

Re:Another one...

[CrankyFool]

You know, it's funny. I manage a software development team that uses Scala to build a pretty big distributed system.

Nobody on this team knew Scala when the team decided it wanted to use Scala to build this product. We still don't actually prioritize Scala as a skillset for developers we look to hire.

It turns out that smart, experienced, people tend to be able to learn whatever particularities of whatever your choice of product pretty reasonably quickly. It's hard enough to find good developers, so we focus on that. Works reasonably well for us.

Re:Another one...

[CrankyFool]

I'd argue if you're hiring just to fire someone in a year -- and you know this in advance -- you're doing it wrong.

Re:Another one...

[Anonymous Coward]

Your podunk company doesn't mean shit.

Re:Another one...

[visualight]

I have learned that when an employer is particularly looking for people with experience using an APPLICATION, don't bother.

Re:Another one...

[Boltronics]

Actually, you couldn't be further from the truth! :)

Salt was my recommendation based on an evaluation of the options at the time. It was selected as the best fit for the company requirements, yes, not for my own personal benefit. I'm sure that other professionals would do the same.

If there aren't currently many job advertisements for people with Salt experience, I can only imagine that it's because the technology is still relatively new so hasn't been a configuration management candidate at many companies until the last year or so. I don't imagine it will take much longer to see adoption of it just as commonplace as the older more established solutions.

Re:Another one...

[pioneerX]

The ancient Egyptians extracted the brain through the nose and stuffed it into a jar. If the industry came up with standardized canopic vessels you could include them with your application.

Re:Another one...

[Lennie]

I would think someone with Python programming skills and experience with Puppet/Chef should be able to use Ansible or Salt just fine.

Re:Another one...

[Anonymous Coward]

Oh god, to be half as clever as you, you smug cunt.

Re:Another one...

[rleibman]

Are you hiring? :)

Re:Another one...

[CrankyFool]

Hell. Yes. Email me at slashdot20131122@ols.inorganic.org if you're interested in the details.

I think I'll pass

[Anonymous Coward]

This guy just doesn't have what it takes to provide usefulness or utility in his columns. In fact, he's probably responsible for more than a little corporate stupidity, thanks to CIOs blithely following his "advice".

Re:I think I'll pass

[Anonymous Coward]

I have to agree. This is a very poor "comparison" which doesn't appear to compare anything, and is downright incorrect and misleading in places. He doesn't appear to have made any actual effort to use any of the tools, so his "comparison" is based on what he read on their websites (and possibly, peoples blogs).

He misses more than he covers. He doesn't even mention the various convergence models; for example, Puppet has no implicit dependencies between actions, so you can't rely on it running the same actions in the same order over any two runs, which can have important implications. He marks Chef down on "Manageability" because it requires a workstation to perform management actions from? Um, and how else would anybody do anything? All of the web UI's for Puppet, Salt & Ansible are equally useless without a workstation to run a web browser on, and he even admits that the web UI for Salt is pretty poor. That's quite ignoring the fact that "knife" is an incredibly powerful tool. He seems to be under the misapprehension that Chef Cookbooks are written in pure Ruby, completely missing the extensive DSL which is entirely analogous to the DSL that Puppet offers.

He didn't even touch on the higher level stuff like data bags in Chef, or the differing levels of orchestration functionality across all four, or availability of third party modules/cookbooks/agents, or the security (or lack thereof) models, or...

I could reduce his entire comparison down to "There's these four things, plus another one I forgot about. They do stuff that's superficially similar. Use whichever one you like the most." Gee, thanks mister.

Re:I think I'll pass

[Lennie]

There were links in the article to articles about the individual products behind a paywall, I would assume they are more detailed.

Re:I think I'll pass

[eschasi]

Not an actual paywall, they only ask for your email address. Not even a password. This strikes me as a fine way to subscribe strangers to mailing lists, sigh.

Re:I think I'll pass

[Lennie]

OK, whatever it is. I just knew I didn't want to look any further ;-)

Security?

[Anonymous Coward]

What about security? Like Salt with its "homemade cryptography" https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc

cdist

[Anonymous Coward]

I've recently been playing around with cdist, which is another configuration management framework.

Configuration is done via shell (sh) scripts instead of XML or some other wacky language. I liked this flexibility. Of course, flexibility comes at the expense of simplicity: the base feature set is small so you end up having to write a lot of code, and the shell scripts you end up writing are really ugly because you have to use their weird constructs. Still, it was pretty easy to learn.

The requirements are really minimal: your "master" machine only needs to have Python 3.2, unix tools like sed, etc. and ssh. The target machine only needs unix tools and ssh. This is also another thing I liked. It means that a bare system can be configured via cdist with minimal fuss.

I kinda liked it, and it worked well when we used it. If you don't mind exchanging easy of use for flexibility, you should try it.

Re:Funny name

[Anonymous Coward]

It's a Thai name.

Puppet Vs. Chef Vs. Ansible Vs. Salt

[FatLittleMonkey]

Article did not contain the review I expected. Would not read again. 0 stars.

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[ruir]

I chose Ansible because it goes in line with my minimalist configuration policy, it works via ssh and doesnt need an agent. Puppet or Chef are very interesting, but use a lot of resources.

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[Serious Callers Only]

unfamiliar with all so i did some quick research. Ansible least transparent Chef not bad, it comes down to Puppet Vs. Salt.

You're seriously presenting your quick google search and no actual knowledge of these products as something we should pay attention to? And your criteria for a deployment system is that they have online support??!?!? Are you even in the market for these products, have you ever used one, and do you know what they do?

I've used Ansible and it's pretty good, really straightforward, plenty of examples and docs and there is a freeware version as well as the commercially supported version. It doesn't require you to run a separate server as puppet does either, you can deploy with recipes from your local machine. To those thinking about using them, I'd say it's the simplest, the most effective and overall the best, though I haven't tried Salt so can't really comment on that.

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[purpleidea]

One reason to prefer Puppet over Ansible is that Puppet tries to add a declarative language layer. This (hopefully) lets you reason at a higher level about the configuration. Ansible is just fancy SSH. In some cases Ansible can be quite useful. But I think we're comparing apples to flamethrowers.

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[Anonymous Coward]

You're seriously presenting your quick google search and no actual knowledge of these products as something we should pay attention to?

The person logged in via Facebook. Does this question really require an answer?

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[Bigbutt]

The little bird is Twitter not Facebook.

[John]

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[FatLittleMonkey]

Insightful?

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[Lennie]

Ansible and Salt are very similar. Both are written (mostly) in Python.

What Ansible already had (yaml templates and agent-less/ssh), Salt now also supports (Salt supports multiple templates languages with Yaml as the default I believe).

What Salt has (zmq transport), Ansible now supports (fireball mode).

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[Lennie]

Salt and Ansible both support/use Yaml as a template language as a declarative language.

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[Anonymous Coward]

Ahh yes. Although I believe that only strengthens my point.

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[Bigbutt]

Agreed. Just being picky :)

[John]

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[ahabswhale]

Yeah, I love puppet's JSON interface which is royally fucked up because if you write legal JSON, then puppet doesn't work. You have to use their fucked up version of JSON. I know they have a Ruby interface now too but it wouldn't surprise me if they fucked that up as well. Seriously, how do you fuck up JSON?!?!

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[purpleidea]

I don't know enough about Salt, but from what I know about Ansible, they don't separate the execution of the declarative language between server and client the way Puppet does. IMHO, this is a clever separation.

Then Puppet adds in exported resources and other magic.

Re:Puppet Vs. Chef Vs. Ansible Vs. Salt

[purpleidea]

I'm not sure if you're serious or trolling, but you're not supposed to "write json".

You write in the Puppet DSL and/or Ruby. Puppet does the rest.

Advanced Puppet

[purpleidea]

I prefer Puppet, but I don't think it's perfect. As a result, I've written some complicated hacks do to complicated things that aren't directly possible in core. I still think Puppet is the closest thing to being right.

Feel free to look through my articles and hacks: https://ttboj.wordpress.com/
Most code available at: https://github.com/purpleidea/

I want everything for nothing

[jabberw0k]

WANTED: Programmer with 15 years experience Ruby on Rails and 23 years MongoDB experience, to help write $5 million package. Pay: $11/hour, 30 hours/week part time (although we expect you to camp out as we supply pizza and beer). Supply your own equipment. Job to last three months.

-- That's why I'm running my own shop instead of trying to go thru a recruiter.

Re:I want everything for nothing

[swamp boy]

Don't forget the rock star part.

Re:I want everything for nothing

[Anonymous Coward]

15 yeas of Ruby experience is possible, the 23 years for MongoDB is the hard part but if you want a wizard that's what you're expected to ask him/her :-)

Re:I want everything for nothing

[Joining Yet Again]

And it works, because many geeks are antisocial sorts who rather than organising their labour will happily walk over each other just to get that little bit of green. Then, when the race to the bottom has been reached, they'll bitch about everyone else being better treated, rather than stopping to ask why it happened and striving to improve their collective lot.

Every sufficiently old once secure job is now tenuous or non-existent. What is secure today will be tenuous in a decade's time.

Re:I want everything for nothing

[Vitriol Angst]

You forgot; "Include on portfolio or website a complete implementation of the latest cool thing I saw in a magazine on an airplane."

Most of the jobs I've seen that are still open are either; "We are just trolling to get personal information" or "Seriously, we do absolutely nothing at this company and figured the WHOLE PACKAGE would just drop in and take care of making a product for us. However we do have HR department to tell you not to make any jokes during work hours and a company email which will send you stuff that's important but never applies to you every 15 minutes."

Re:I want everything for nothing

[Vitriol Angst]

I'm going to start putting down that I've got 50 years of iPhone programming experience.

Honestly, I've really only watched two 'iTunes University' video podcasts on the subject, but I'm showing my prowess in marketing and echoing that rock solid "fast advancement for employees with a go-getter attitude" by applying that same positive attitude and respect for the truth to my resume.

Re:I want everything for nothing

[Vitriol Angst]

Except of course executive, or VP who married the daughter.

Re:I want everything for nothing

[tobiasly]

And it works, because many geeks are antisocial sorts who rather than organising their labour will happily walk over each other just to get that little bit of green. Then, when the race to the bottom has been reached, they'll bitch about everyone else being better treated, rather than stopping to ask why it happened and striving to improve their collective lot.

Organized labor? Uh no, we're too smart for that. I can't speak for everywhere else but where I live there are plenty of well-paying development jobs and I've never seen the type of behavior you describe among my peers.

Every sufficiently old once secure job is now tenuous or non-existent. What is secure today will be tenuous in a decade's time.

Yes, it is a field where you must keep your skills up to date and be willing to switch jobs if market or other conditions dictate. If you stay in one position too long and let your skills stagnate you do run the risk of becoming obsolete.

Re:I want everything for nothing

[Anonymous Coward]

Preach it!

"I had this idea for an app, but don't have any money or skills, I would like to pay you nothing, take no risk, and reap all of the rewards. Send applications right away please!"

Re:I want everything for nothing

[Anonymous Coward]

Sometimes I feel like going on interviews, despite not looking for work, just so I can get to the "rock star" part and detail how much time (I don't really) spend snorting blow and sticking my member into screaming girls who have blown my roadies to get into my tour bus. ...It's a pity that "assault" is a thing, because people who use "rock star" in the context of IT really haven't been beaten enough.

Re:I want everything for nothing

[Anonymous Coward]

Its only a race to the bottom for the incompetent - they find their level quickly, and rightfully so. For the competent, income increases.

Re:I want everything for nothing

[Joining Yet Again]

Organized labor? Uh no, we're too smart for that.

LOL - OK buddy. In the UK, Directors have a union (Institute of Directors), business owners have a union (CBI), farm owners have a union (NFU - which actually comprises a lot of wealthy landowners, explaining the often right-leaning politics), doctors have a union (BMA), university lecturers have a union (UCU)... but you're too smart for that because you DO COMPUTERS. Carry on with that rat race!

I can't speak for everywhere else but where I live there are plenty of well-paying development jobs

Oh, that's all right then. And there were plenty in 1999, too.

and I've never seen the type of behavior you describe among my peers.

Then you work with your eyes closed. That sort of behaviour exists throughout society - it's just more prevalent among antisocial types.

If you stay in one position too long and let your skills stagnate you do run the risk of becoming obsolete.

Yeah, if you let your skills stagnate in ANY job then you run the risk of becoming obsolete. Wobegon effect - all developers are just fabulous, eh?

Thank you for demonstrating my point.

Re:I want everything for nothing

[Joining Yet Again]

Because, of course, more competition between developers means a greater supply of willing labour means... an increase in wages?

Your understanding of economics - it is broken.

Puppet Vs. Chef Vs. Ansible Vs. Salt

[slayerwulfe]

unfamiliar with all so i did some quick research. Ansible least transparent Chef not bad, it comes down to Puppet Vs. Salt. Had to search Saltstack for information on google to find a result for Salt. i believe most would go with Salt and that seams to be the case, minimal intelligence required. Puppet is very intriguing simply because it requires a higher level of intelligence. Salt offered a tutorial but Puppet offers a direct line of communication to solve problems. in my 15 min. search i would choose Puppet as best choice for the present. slayerwulfe

Puppet, Chef, Ansible, and Salt - huh!?

[Anonymous Coward]

Using meaningless words as names of software packages has got to stop. What are Puppet, Chef, Ansible, and Salt? They are "configuration management and orchestration tools" - orchestration? Is this MIDI software? I guess the software world has gotten to the point of being so uber-specialized that if you have to ask, you don't need to know.

Re:Puppet, Chef, Ansible, and Salt - huh!?

[Anonymous Coward]

"Orchestration" is a commonly-used word which refers to coordinating the actions of individuals so that they function together as a group. For example, musicians in an orchestra. Or a servers in a data centre.

Re:Puppet, Chef, Ansible, and Salt - huh!?

[gbjbaanb]

orÂchesÂtraÂtion (Ãrk-strshn)

2. Arrangement or control: orchestration of events.

Is most common use is for musical arrangement, but it really roughly means "organising things".

Re:Puppet, Chef, Ansible, and Salt - huh!?

[3.5 stripes]

orchestration (ôrk-strshn)
n.
1. a. A musical composition that has been orchestrated.
    b. Arrangement of music for performance by an orchestra.
2. Arrangement or control: orchestration of events.

Try reading a bit.

Re:Puppet, Chef, Ansible, and Salt - huh!?

[Anonymous Coward]

Using meaningless words as names

Most names are in fact "meaningless", except as a name.

orchestration?

Yes, your inability to understand the English language is everyone else's fault.

Ansible lol...

[Notabadguy]

Am I the only one who saw Ansible in the article and was expecting a discussion about FTL communications?

Re:Ansible lol...

[Crudely_Indecent]

I was right there with you, thinking "what does puppet, chef and salt have to do with Enders Game?"

Re:Ansible lol...

[Notabadguy]

Well, I didn't throw Ender's Game out there because Orson Scott Card's use of it was one of the latter references. Ursul K. Le Guin came up with it in Rocannon's World, and her 1974 novel "The Dispossessed" works through the invention of it.

OSC borrowed the term.

Re:Ansible lol...

[Crudely_Indecent]

And I learned something new today - reading list adjusted!

heres how that cage match comes out

[nimbius]

imagine a room full of angry hitmen.
Puppet: plans to beat you to death, but when his arm gets tired he cant switch to the other arm. instead he grabs a box of markers and proceeds to write an angry letter on your face.
Chef: is competent enough to kill you in your sleep, knows everything about you and can even draft random passerby for practice. Shes spending the next 2 months assembling a rifle for each possible scenario she may find you in, and redefining some of the most effective murder/homicides in history so they work just for you.
Ansible: A nice killer in a business suit that will probably smother you and dispose of your corpse in an entirely predictable way. The 'Murder She Wrote' of configuration management, she'll win an oscar once you're dead.
Salt:as of this writing, salt last killed 54 days ago and currently stands as the less-than-well-known of your potential murderers. Salt has pretty good ideas on how you should die...its just puppet has been maiming folks for way longer and chef's gotten so popular that people cant walk through the streets without hearing someone gloat about how wonderfully she kills. Salt has a manifesto and a pretty sizeable arsenal...someone just needs to send a contract over, or a phonecall, or whatever it is chef does when she gets to murder folks.

Good article

[Anonymous Coward]

Even as a rube I got what the story was about in the first paragraph.

What about Juju?

[Anonymous Coward]

How does Juju compare? (https://juju.ubuntu.com/)

Re:What about Juju?

[Lennie]

Well, there is nothing which keeps it directly tied to Ubuntu. But it basically is right now.

Security concerns and efficiency...

[Pav]

This stuff is overdue in smaller shops - stay with me on this for a second. The smaller guys need to become more efficient and secure, and automation really helps. Potentially the small end could benefit MORE from automation than the big guys already have - automation is a much more disciplined and useful form of sharing information. Docs are often incorrect or incomplete - automation imposes discipline, and also allows the author to benefit from the end result. Time savings for everyone are often huge.

I'm regularly on #fusiondirectory on FreeNode (IRC) along with a few others who are working towards this kind of thing (using the Munich software as a base). Anyone else wanting to join us is welcome.

Oh, yes.

[Anonymous Coward]

Programming is hard -- let's go shopping.

(With a tip o'the hat to Jeff Atwood).

Build your own packages

[SCHecklerX]

rhel-only shop, I've had good luck just packaging my own stuff and using yum with my own repositories. Then keeping each server up to date is a simple matter of 'yum clean all & yum groupupdate whatevergroups'

Re:Build your own packages

[Anonymous Coward]

Did that with Debian at the last job.
Building your own packages has it's place. Deploying software and static configuration files it works for. When you start trying to define more than two different configurations for the same file between the systems, I got bogged down in the package manager details. These are much easier to handle in one of these tools.

In the long run I find augeas (used by puppet) to be far more readable than a homegrown shell/perl script to modify a file configuration.

At the current job, I expect to be deploying custom packages, but those will be installed via puppet which will be doing the base system configuration.

Re:Build your own packages

[Anonymous Coward]

Great, and what about all the other stuff that configuration management & orchestration tools do besides installing packages?

Yeah Right

[Browzer]

and two positives make it a negative :)

Swedish Chef

[Anonymous Coward]

Did anyone else think of the Swedish Chef when reading the headline?

Re:Swedish Chef

[Anonymous Coward]

The Puppet Chef is not worth an ansible of salt!

Serverless Puppet

[gozar]

Puppet can also run with out a server. You can clone your puppet repo and simply run "puppet apply main manifest.pp" The server gives you more control over what the machine receives, so each machine wouldn't have access to items such as ssh keys or user info that doesn't pertain to the machine.

Re:Serverless Puppet

[Anonymous Coward]

Whoa! You mean just like an admin box with an NFS share and some shell scripts? wow!

The reason I use Salt..

[bacchus612]

Architecturally, Salt is based on a Pub/Sub message queue (they use ZeroMQ to build it) - this allows the master node to send commands to a large number of minion nodes with very little overhead. It is also pretty easy to hook into the message queue on either master or minion nodes, so you can use it to send custom "event" messages along the queue (with authentication and all the fixin's) which can be used to trigger commands or configuration changes, or to hook into external systems.

I am using this to experiment with "event-driven architecture" currently - doing things like automatically updating proxy configurations when a new application server comes online, or removing an A record from DNS when a host is terminated. I don't think it's the end-all, be-all of configuration management, but Salt does provide a lot of flexibility to implement some pretty fancy infrastructure.

Shameless plug: If anyone is coming to SaltConf 2014 in Jan., I'll be giving a talk about the above (I don't work for SaltStack, it's just neat stuff)

Pfft. Old news. Let's talk META-tools!

[daboochmeister]

Puppet, Chef, yadda yadda - the REAL action is in the META tools for automating all the Puppet and Chef etc. systems worldwide. PuppetMaster (pulls all the Puppet's strings), GordonRamsey (yells at all the Chefs out there). Let's not kid ourselves, THAT'S where Skynet is going to emerge.

How well do ANY of these handle Windows?

[daboochmeister]

Haven't evaluated in over a year, but a stark finding from that timeframe was that making Puppet or Chef handle Windows was a force-fit, at the very least, and pretty crude. Have things advanced? How well do any of these solutions manage the byzantine complexity that is Windows CM?

Re:How well do ANY of these handle Windows?

[Anonymous Coward]

You want CFEngine for Windows and Unix at the same time. Puppet can't even manage Windows file permissions beyond the Unix "user/group/other" concept, and Chef is just a batch language.

How would you even play

[Anonymous Coward]

"Puppet Vs. Chef Vs. Ansible Vs. Salt" sounds like the worst version of rock paper scissors ever

Puppet *sigh*

[Ixpath]

The only reason to choose Puppet over Chef is if you are a sysadmin who can't program. Choose Salt if you prefer Python over Ruby.

Re:Puppet *sigh*

[Anonymous Coward]

Please tell me on what planet you live on where puppet manifests isn't "programming"

Offtopic (Re: your tagline.)

[grep -v '.*' *]

Good people go to bed earlier.

Lately I've started going to bed about 4 in the morning. (Severed.) Assuming you go to bed about 9 or 10 at night, that must means I'm MUCH gooder than you.

Great comparison, BTW.

Re: shameless plug

[mixmasta]

If anyone is looking for an even simpler solution, I've package up my own project and open-sourced it. It's called pave, and has few dependencies, just PyYaml and fabric:
        https://bitbucket.org/mixmastamyk/pave
Would love to get more feedback.

Re: shameless plug

[mixmasta]

packaged ;)

Another speaker of latin-derived language

[Anonymous Coward]

Hum I think there is a confusion here... In French too we use the double negative but the original sentence is perfectly clear and would translate with an identical structure (there is a negation in each proposition)... But may I misunderstodd the "negative concordance" (I only googled a bit on it).

Puppet vs. Chef?

[Anonymous Coward]

Bork, bork, bork, bork!

motorcycle tours in vietnam

[Anonymous Coward]

Well, I didn't throw Ender's Game out there because Orson Scott Card's use of it was one of the latter references

  motorcycle tours in vietnam

Re: shameless plug

[styrotech]

Were you aware of Paver? http://paver.github.io/paver/

The names could get a little confusing as pave is also a Python project in nearly the same space.

Re: shameless plug

[mixmasta]

I have seen it but couldn't figure out what it does after reading the docs. Seems like a make alternative. I can't think of a better name unfortunately.

my own review

[Anonymous Coward]

I don't know about ansible or salt however chef and puppet just seem like the absolute wrong way to do deployment to me. My needs are very basic, install some packages, edit some configs and deploy the latest code in git on multiple linux boxes. Most of my experience is with Chef which basically rewrites the linux package manager in ruby.

I really don't understand why someone doesn't just make a good deployment frontend over the debian packaging framework. Smart guys already figured out all the awesome deployment stuff such as rollbacks, etc. Why people feel the need to rewrite all that into a poorer implementation of a package manager I'll never understand.