Slashdot Mirror
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.'"
In English, unlike many other languages, a double negative means a positive (sarcasm aside). The guy is agreeing with you.
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.
Thanks for pointing that. And yes, English isn't my native language
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..."
Look up "negative concord".
It's a Thai name.
Article did not contain the review I expected. Would not read again. 0 stars.
Science is all about firing a drunk pig out of a cannon just to see what happens.
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/
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.
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.
Am I the only one who saw Ansible in the article and was expecting a discussion about FTL communications?
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 :)
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.
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 people go to bed earlier.
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.
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.
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.
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.
What, me worry?
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)