A Biased Critique of Ansible vs. Salt Search Results

Author: Nicholas M. Hughes

So… here I am, gearing up to write a blog post comparing the features of Ansible and Salt for probably the one-hundredth time while somehow finding something new to say.

My business partner and resident Network Guru, Jon Gordon, has been getting hit with a lot of questions surrounding this topic in the context of network automation. As the resident Automation Guru, it fell on me to give him a resource that would address these questions… hopefully in a format that make sense. As part of my initial research, I typed into the browser the same thing that others will likely be typing when they stumble across this post: Ansible vs. Salt

While reading through the list of top results, it quickly became apparent that it might be worthwhile to provide commentary on the existing “Top Dog” search results in May of 2019. As a SaltStack Authorized Partner, I’m clearly biased here… but I will say that my company is aligned with SaltStack because we believe in the technology and we’d use it regardless of whether or not they were handing out badges. Disclaimer finished. In the first section I’ll provide a brief overview of the applications, then go over some of the top search results on this topic “live-Tweeting” style, and finally I’ll see if I can include some original nuggets in a section at the end. Open up some side-by-side browsers and let’s jump right into the list.

What’s an Ansible? What’s a Salt? Why are they always fighting?

According their website, “Ansible is a universal language, unraveling the mystery of how work gets done”. I’m not really sure what that means, so I’ll take a shot at my own definition. Ansible is an open-source application, configuration, and cloud deployment tool. It’s very lightweight by default, in that it only requires the Ansible console application to get started. It implements agentless connection mechanisms (usually SSH for systems/devices that support it natively and WinRM for Windows systems) to connect and perform actions on remote devices. The SSH transport makes it attractive for configuring lightweight devices and network equipment, because they’ll generally support SSH. Additionally, it connects to public cloud and container management APIs directly in order to stand up and configure cloud infrastructure and containers. It has a UI component called Ansible Tower, which provides a centralized location from which to perform the aforementioned actions as well as reporting and scheduling of jobs. I’ve never used it myself, but I understand that Tower is free up to 10 connected devices.

Salt is an event-driven automation and orchestration platform for remote execution and configuration management. In the default configuration, client agents called “minions” are installed on remote systems in order to provide access to super-fast event bus communication to the master via ZeroMQ transport. Additionally, Salt can employ an agentless configuration with it’s Salt-SSH implementation. Salt can also communicate and control devices via it’s Proxy Minion capability. Proxy minions are a Salt feature that enables controlling devices that cannot run standard Salt Minion software. Examples include devices that run a proprietary OS, devices with limited CPU or memory, or devices that could run a minion, but for security reasons, will not. This proxy capability is used quite a bit for network devices. Salt doesn’t include a UI in its open source offering. SaltStack Enterprise (SSE) provides that capability. If I’m being honest, I thought SSE was unnecessary for a long time. It just provides a UI for people who don’t know how to use a command line, right? However, the reporting capability is really nice and the release of the SecOps module for security and compliance is really a game-changer. It elegantly solves a problem with which so many organizations struggle.

Salt and Ansible both define their configurations using YAML, with slightly differing syntax. The workflow for implementation in Ansible usually involves pulling down your tasks/playbooks from Git, modifying if necessary, pushing out the configurations to devices, and then committing back to Git so others on your team can do the same thing. Conversely, Salt has a central location for the configurations on the master, so there is less capability for drift when someone decides to go rogue and stop checking in their changes. The biggest differentiation in my opinion is reaction to events on remote devices. There really isn’t a concept of this in Ansible. You can schedule jobs to reach out and enforce configuration state on an interval or actively poll systems for changes… but the remote system can’t initiate an event because there isn’t any software installed on the device. On the other hand, Salt was built for exactly this use case. It has a great mechanism for triggering events from a minion in order to take action or notify someone of a change. An example might be watching an important configuration file for changes, triggering an event if it’s modified, and then having the master push out the “proper” configuration and squash local changes. The sky is the limit with what you can accomplish with the event bus.

What are people saying about my friends on the Interwebs?

Ok… Let’s see what else is out there on the subject.

Ansible vs Salt

Number one search result for Nicholas Hughes in May of 2019! Oh! Hey! It’s from November of 2018… Oh wait… No… It’s clearly not. It was updated in November of 2018. The references are from 2013 and 2014, so I’d wager this post is from 2014 sometime. Let this be a cautionary tale to take what you find on the Internet with a grain of Salt (pun intended).

On the Ansible side, there is mention of the parent sponsor company… which is now Red Hat and has been since 2015 I believe. Oh God, this is old. Most of the rest of it is fairly accurate to my knowledge. Not much to see here.

Now, on to the Salt information.

There’s a section speaking to the motivation for the creation of Salt stating “It was also developed in response to dissatisfaction with the Puppet/ Chef hegemony, especially their slow speed of deployment and restricting users to Ruby.” I won’t speak for Thomas Hatch, but based upon his actual words it seems that he was more concerned with creating a super-fast unified platform to manage systems at scale. I’ve met Tom in person, and he doesn’t strike me as the type to form a rebellion against the oppressive Puppet/Chef regime just because they were authoritarian overlords. Those tools simply didn’t fill the need he had.

I just read “Salt is sort of halfway between Puppet and Ansible” and nearly lost my mind… Let’s just skip over that one.

…but it didn’t get any better… “it supports Python, but also forces users to write all CLI commands in either Python, or the custom DSL called PyDSL” … I’m not sure what they’re getting at here. “Writing all CLI commands” feels like they’re referencing Execution Modules. If so… yes, you’ll need to develop custom execution modules in Python… the same language in which the core of Salt is written. One positive is that extending Salt is ridiculously simple compared to the core of Ansible. Compare the layout of Salt’s module code to any code written in the core of Ansible and tell me I’m wrong. If you’re writing your own custom modules outside of the core of Ansible, then it gets much easier. You basically just need to write something that dumps JSON results. If they’re referencing the state format, then the statement is not accurate… at least in 2019 and as far back as 2015 when I first started using Salt. Salt uses YAML for states, just like Ansible roles/playbooks.

“Now the bad news.” Uh oh… There’s bad news? “Some still feel that the master-minion setup is less secure than the pure SSH in Ansible. ZeroMq doesn’t offer native encryption, so Salt has to include an extra layer of Kevlar by way of its own AES implementation. And Salt uses persistent daemons for master-minion communication between nodes, which introduces its own (admittedly small) performance hit – though this setup excels in large deployments.” Let’s break it down. The AES algorithm doesn’t magically become less secure because you’re running on a transport that doesn’t natively support encryption. Guess what algorithm a lot of your servers are probably using for SSH… AES. Sit down “My servers use ECC” guy… I know there are other algorithms out there. Anyway, the assertion that installing minion software introduces a performance hit is slightly misleading even though they say it’s very small. It’s so negligible that it really shouldn’t be mentioned. Also… Welcome to the age of endpoint agents.

SaltStack vs Ansible Revisited

Phew… That first one took a lot out of me… just in time for the article which revisits the previous article!

“Salt—now known as SaltStack—is a modular, Python-based CM tool designed for high-speed data collection/execution.” Salt (or Salt Open) is the Open Source software. SaltStack is the company. SaltStack Enterprise is the paid software. Also, it’s not (just) a Configuration Management tool. I’ll probably harp on this in a later section, but Salt can do so much more than CM.

Ooooooo… This article has a list comparing features and unexplained pie chart scoring! Let’s paint by numbers!

1. Capability Set - I’m not even sure why this item has this title… There’s absolutely no mention of the overall capabilities of each, unless you count the fact that they’re both “highly capable IT automation/CM offerings”… Ugh. Again, I’ll save this for later.

2. Usability / Learning Curve - Ok. This one is fair, but not really explained well. Most people will admit that Salt is “harder to learn” than Ansible. I’d argue that is due to the fact that it can do so much more. It’s a lot like comparing a multi-tool to a passenger jet… One is clearly easier to use than the other, but you’re not going to fly to Chicago on your Leatherman.

6. API and Extensibility - I’ve heard many people lament the lack of a proper Python client for Ansible despite the fact that it’s a Python application. I’m completely uncertain if this has changed recently, but it’s worth mentioning if Salt is still the only contender with that distinction. Also, it seems that they’re comparing Ansible Tower’s REST API to Salt’s “limited” Open Source REST API… Apples to apples, Ansible does have a free REST API in AWX, but I haven’t played with it to see if it’s more or less “limited” than Salt’s API and SaltStack Enterprise’s REST API is way more robust than this article seems to give it credit for. To be clear, “limited” is their word, not mine.

9. Control Capabilities - “As mentioned previously, SaltStack Enterprise’s ZeroMQ messaging data bus gives it significant speed advantages, while Ansible’s lightweight, agentless architecture make it more lightweight and easier to manage.” They’re not really comparing apples to apples here. Please refer to Exhibit A for more information regarding Salt’s agentless solution that uses… GASP SSH AS A TRANSPORT! Yes, Salt’s default transport is ZeroMQ but it can also use SSH, so it technically gets a check in both columns.

Chef vs Puppet vs Ansible vs Saltstack: Which Works Best For You?

This article isn’t bad… although the layout makes it hard to follow for my old eyes. I think the main thing to take away from this one is that she seems to be comparing the Enterprise offerings for each product, but doesn’t mention it other than factoring cost into the comparison. FWIW, I think that comparing the four major contenders in this arena should be given way more detail than is covered in the article.

Suggestions on Ansible vs Saltstack?

Kudos to erewok for some great points on Salt and Ansible. Variables and the magical Jinja fields like those found in Playbook Conditionals in Ansible give me headaches. Salt is way more explicit in handling these cases.

Take this Ansible example:

tasks:
  - name: "shut down Debian flavored systems"
    command: /sbin/shutdown -t now
    when: ansible_facts['os_family'] == "Debian"

That when section is raw Jinja… but it’s not in curly braces, which could be misleading to some. Here’s an equivalent representation for Salt:

{%- if grains['os_family'] == 'Debian' %}
shut down Debian flavored systems:
  cmd.run:
    - name: /sbin/shutdown -t now
{%  endif -%}

Your Jinja looks like Jinja and your YAML looks like YAML… just like mom used to make.

Ansible v.s. Salt (SaltStack) v.s. StackStorm

I really like this article. Unfortunately, it also falls into the same “Agent vs. Agentless” trap as other articles in one of the sections. Salt SSH is a real thing, and I’m starting to think I need to scream it from the rooftops. Near the end, the author does briefly mention salt-ssh… so, that’s a positive. Overall, this is really well written. I’d definitely recommend that people read this article. You also get the bonus of learning a bit about StackStorm as well.

Finally, an Unoriginal Thought

I thought that I might actually have more unique things to say, but that last article written by Anthony Shaw hit the nail on the head pretty well. He even dropped this nugget “Salt does a lot, so typically when you hear Salt-fans comparing it with Ansible you’ll get a response of ‘yes, but it does sooo much more’.” that pretty much mirrors exactly how I acted earlier in this article. Read all the things he writes, because he’s clearly very smart.

TL;DR

• Read this post, but keep in mind that two years have passed. Some things have evolved.

• Salt and Ansible have very different sets of capabilities. It’s like a Venn Diagram… except one of the circles is smaller than the other… and it’s inside the bigger circle… and the smaller circle is Ansible.

• Salt is capable of SSH transport.

• Salt’s network automation capabilities have really picked up over recent years, and I understand this is in large part due to Mircea Ulinic. (No disrespect to any other contributors out there.)

• SaltStack Enterprise now has a killer app! Check out the SecOps module for SaltStack Enterprise.

I’m really not an Ansible hater. I think it’s a great tool for a lot of use cases. However, I do think that Salt’s capabilities are often mischaracterized in these comparison articles. It’s my opinion that viewing Salt in the context of Ansible’s capabilities greatly reduces your ability to see all of the benefits that Salt can provide.

Thank you for reading all the way to the bottom! …or at least skipping down here to see if there are any worthwhile conclusions. I set out with the goal of writing a post that was much different than the one that materialized, so I hope it was somewhat informative (through other people’s information) and somewhat enjoyable (if you can tolerate stream-of-consciousness writing styles).