Salt: Like Puppet Except It Doesn’t Suck

Repost from http://blog.smartbear.com/devops/a-taste-of-salt-like-puppet-except-it-doesnt-suck/

Have you gotten frustrated with Puppet? Corey Quinn offers an impassioned argument for his favorite open source alternative.

If you’re responsible for the care and feeding of multiple servers, and you haven’t heard about configuration management yet, you have not been paying attention.CFengine was one of the first configuration management systems that was deployed in anything approaching widespread use, and was followed later byPuppet and Chef. A bit over two years ago, Salt Stack‘s “Salt” entered the market, and took a radically different approach to the problem of “configure all of my servers to do X.”

Salt started life as a remote execution system: a class of software applications written to address concerns of the form, “I have this command I want to run across 1,000 servers. I want the command to run on all of those systems within a five second window. It failed on three of them, and I need to know which three.”

Other systems were designed to do this, of course, but they failed in several ways. MCollective (which Puppet Labs acquired several years ago) was (and remains!) fiendishly complex to set up. Chef works atop ssh, which — while the gold standard for cryptographically secure systems management — is computationally expensive to the point where most master servers fall over under the weight of 700–1500 clients. Salt’s approach was far simpler.

Salt leverages the ZeroMQ message bus, a lightweight library that serves as a concurrency framework. It establishes persistent TCP connections between the Salt master and the various clients, over which communication takes place. Messages are serialized using msgpack, (a more lightweight serialization protocol than JSON or Protocol Buffers), resulting in severe speed and bandwidth gains over traditional transport layers, resulting in in the ability to fit far more data quickly through a given pipe. This translates into a non-technical statement of, “Salt establishes a persistent data pipe between servers in your environment that’s extremely fast and low-bandwidth.”

What made Salt compelling for my use was that, following the steps in the tutorial, all of what I just described took less than 20 minutes to get working. Someone new to configuration management can be productive with Salt before lunchtime, and someone who’s familiar with configuration managers can perform complex tasks relatively easily. Simple is good.

The folks at SaltStack seem to be unwilling to settle for merely “doing what other configuration management solutions can do.” Part of the value that Salt is adding is in their ecosystem of other offerings tied into Salt.

For instance, Salt-cloud serves as an orchestration layer that can spin up instances in EC2, Openstack, Linode, or other cloud computing providers. The idea is that Salt lets you not only define configuration within running instances, but also handle the initial provisioning, ongoing maintenance, and deprovisioning of the entire instance swarm.

Salt-virt is a newly released module that serves as a well-architected wrapper around the libvirt, a popular virtualization library for KVM, Xen, OpenVZ, and others. This is similar to salt-cloud, but rather than making API calls to a third-party provider, it makes libvirt calls to hypervisors on your behalf to instantiate new virtualization guests, as well as providing monitoring data around running instances.

Salt-vagrant is a salt extension that lets you use Salt to manage Vagrant instances. Vagrant is an established project that wraps around a number of existing virtualization providers to allow for extremely quick provisioning of disposable, consistent environments. This is targeted specifically at developers, to solve the fairly common “Develop on a Mac to deploy into a Linux environment” library problems that sometimes crop up.

Salt-monitor is also in the works as one of the next major milestones. This is intended to serve as a soup-to-nuts monitoring solution that scales well, by replacing serial checks iterating through an environment with broadcast conversations, such as, “All servers: Tell me if you don’t have enough free disk space.”

Lastly, salt-ui is currently in early alpha stages. While it’s still in early development, it’s designed to be a Web interface to Salt, ideally making Salt administration even easier for users who have a bit of trepidation around using the command line. While not yet ready for prime time, it’s worth keeping an eye on as development progresses.

Perhaps the most compelling aspects to SaltStack is its vibrant community. Despite Puppet’s nearly six year head start, Salt boasts more contributors to its code base (as per Ohloh.net), a superior comment-to-code ratio, an increase in year-over-year commits, and a lower barrier to entry for new contributors. Community support is provided both via an active IRC channel (#salt on irc.freenode.net) and on the salt-users mailing list.

Having stood up a number of different configuration management systems across a wide variety of environments, I’ve yet to find a solution that’s as rapid to deploy, simple to scale, or as well architected as Salt.

Ideally I’ve given you a bit of a taste of Salt. I hope it whets your appetite.

UPDATE: Since this post was published, I’ve been in contact with a number of Chef aficionados who have informed me that my understanding of the Chef client <-> server communications model was severely flawed. Chef uses https to communicate, not ssh, and its bottlenecks have previously been cited as being based in implementation details of Ruby / CouchDB. To my understanding, this has largely been mitigated in recent versions; my apologies for the error.

COMMENTS:

Luke Kanies says:

June 24, 2013 at 12:44 PM

Why is it that everyone feels the need to dump on things, just because they like something else?

I’m biased, because I wrote the damn thing, but Puppet clearly doesn’t “suck” — it’s in use by thousands of organizations, and tens of thousands of people, many of whom are passionately fond of it. It might suck for you, or you might suck, or it might just not be appropriate for your use cases and/or experience.

It’d sure be easier to have a constructive conversation if you didn’t start out this way. Let’s stick to the merits of the tools, rather than just casting aspersions. Hopefully the rest of the Salt community is more focused on solving their users’ problems than you are.

I’m happy to see different approaches on the market, but Puppet and Salt aren’t that comparable that I can see. YAML is not a configuration language. I look forward to seeing you trying to cram variables and iteration and functions into YAML, for instance; yuck. There’s some great new tech here, and I agree the simplicity is great, but don’t act like you’ll be able to build truly reusable solutions without a bit more functionality than yaml provides.

Of course, your 3 steps is far more than that. Puppet is just as easy:

First, install Puppet and Mcollective and Facter and everything else it needs.

Second, set up all of the SSL keys and make sure it all works.

Third, write the code that automates your whole infrastructure.

That’s obviously stupid, like the days when the linux people would say “step 1, recompile your kernel”. It’s easy to say something is simple when you get to combine and skip steps.

And of course, one of the reasons Puppet Enterprise exists is to make the whole thing super-simple for the majority of our users. If you want a complex, hand-tuned setup, you can, but if you just want it to work, bam, it does.

david karapetyan says:

June 24, 2013 at 4:55 PM

One could just as easily say that Puppet is not a configuration language. Honestly, you had all the power of Ruby at your disposal and you just had to layer something else on top of it. Chef on the other hand does the right thing. Pure Ruby + reusable, idempotent code components. Give me a stack trace and not some mangled error message that is a combination of a parse error, a stack trace, and something about failed constraints.

Luke Kanies says:

June 25, 2013 at 1:01 AM

Meh. It does the right thing from your perspective. Weirdly, not from the perspective of the tens of thousands of Puppet users. Chef is great as long as you like writing gigantic distributed applications that run as root and are ok with no simulation mode, all clients having read/write access to a central database, and don’t mind idempotency only existing for the parts where you feel like it.

The truth is that the DSL is a trade-off. You don’t like that trade-off. Sweet. Enjoy your stack traces. Weirdly, I spent an hour with a Chef user last week who complained mercilessly about the stack traces and really just wanted error messages. Like, with line numbers and file names. Huh, so wait, your opinions don’t map to every other person’s opinions? Weird.

I’m totally fine with you saying X works better for you; it’s a stretch to go from that to saying it works better for everyone.

I personally love riding my bike to work; if you don’t, I assume that you’re just wrong, rather than having different priorities. Right?

david karapetyan says:

June 25, 2013 at 4:45 AM

I would say that Puppet’s DSL provides some kind of trade-off if it actually did provide any. You know what is a trade-off? Static types for better performance optimizations both at compile-time and run-time. What does the Puppet DSL give me in return for taking away the top-down, left-to-right flow of imperative logic? Nothing except for weird errors about unsatisfied constraints. Half the time it steamrolls over failed constraints and the other half of the time it provides a cryptic message about something that I have to chase down to some .pp file which is not even the source mentioned in the error message.

Ansible and Salt are going to win in the end because they approach the problem from the right perspective. Orchestration and configuration management is a subset of a robust RPC mechanism. Puppet, as somebody said, is Ruby hit with a truck and then kept alive on life support. If I was you I would improve upon RPC capabilities and get rid of the nonsense that is MCollective’s DDL files because as usual there is no trade-off here. All it does is add verbosity and constraints and gives nothing back in return. Not to mention all the nonsense with Timeouts.

We can continue to argue about this if you want. I have all sorts of opinions backed by actual production use of both Puppet and MCollective.

binford2k says:

June 27, 2013 at 12:03 AM

> What does the Puppet DSL give me in return for taking away the top-down, left-to-right flow of imperative logic?

It gives you a state model, which means you don’t have to write imperative logic. You simply describe the state you want the system to be in and trust in your tools instead of micromanaging like a PHB.

david karapetyan says:

June 27, 2013 at 2:08 AM

And what exactly is this state model? Do you even know? It sounds pretty vague and I don’t see a definition in your answer anywhere. Do you know what is a formal state modeling language? I’ll give you a hint. A guy by the name of Alan Turing came up with it and then there was this other dude called Alonzo Church. Smart cats in general. You and Luke Kanies, just regular cats. Oh, and there is this other tool I kinda like and trust. Most people think it’s called RubyOnRails but really it’s called Ruby and it just works.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.