The Fight of Giants - Ansible vs Salt

2022-04-22|By Stanisław Szymański|Code

As you've already noticed, this article is pitting Ansible

against Salt, in an epic fight for your attention. But this is not a kind of fight you'd expect - no blood, tears, nor winner or loser. The only thing I'd want to accomplish here, is to help you understand both tools enough, to pick your own favourite when the time comes.


Don't expect a clear answer at the end - "Salt is bad, go Ansible only" or "Ansible sucks, use Salt instead" - but I hope, that after you'll read this article, you'll be able to choose which side will you take, on your own.


You ready? Great, let's begin.

Round One - the entry barriers - FIGHT!

Ansible is definitely much better when it comes to a fresh start. To be honest, it's primitively simple to get started with - you could get your first few-tasks wide operational playbook in under half an hour. Things that would be complicated to understand or handle, are kept hidden under the hood here. Ansible leverages the traditional SSH connections as its main method of operation, with almost nothing to pre-configure. The documentation

is pretty well written and understandable, provides easy to follow examples, and with a few minor exceptions, is kept well up-to-date.


In contrast, Salt isn't something you'd instantly comprehend, if you didn't touch similar tools before. The concepts of "Masters & Minions"

, "Pillars", "Grains", et cetera... It's a lot to take on. And if you won't take this on, you won't get far. Things get progressively harder, as you go deeper, and while it's expected - this may really hit you hard at some point. The documentation isn't as pleasant, sometimes I did even found it hard to understand (Fun fact: There's a documentation chapter called "Salt in 10 minutes" and I'm sure that understanding all of it takes a lot more than 10 minutes.), and had to rely on Google, Reddit, and fellow engineers, to get things right. The main method of operations here is the Master-minion relation, which I'll explain in a second.


If you're not a seasoned Engineer, stick to Ansible. If you're experienced enough and if you have a bit of technical knowledge & understanding of such tools already, Salt might be the better choice.

Round Two - operation methods - FIGHT!

Agent, Agent-less, Master-minion, Masterless, oh dear, a lot to handle. So, let's put it simply, shall we?

Salt's Master and Minion relation, basically means:

  • There is a Master, a command center from which you're applying the Salt State, that gives out tasks to Minions and expects them to deliver results.
  • There are Minions. Workers, that handle task execution on remote hosts, and communicate with the Master, reporting on the current state of affairs.

Ansible on the other way, does not employ such tactic - instead, the device from which you execute the playbook is the head of the entire operation - hands out tasks, supervise execution, exports and reports results to you. What about the agent and agent-less modes though? That's another thing both tools implement differently. Ansible does not rely on agents overall - the "head" executes SSH commands itself, without any help from beyond. Salt has three base modes of operation

:

  • Agent and Server (Master server sends commands and configs, agents handle tasks and return the results to Master)
  • Agent-only (No Master - the Agent is working on its own, handling configured tasks)
  • Agentless (Similiar to Ansible, but not really)

The third mode I've listed went pretty much un-explained, as you've probably noticed. That's because it is a bit more complicated, and I thought that it could use some good ol' clearing up. When you're running Ansible playbook on a target host, you're just passing SSH commands and actions to this host. The only requirements are the libraries and prerequisites of applications or tools you will run on this host with your playbook - e.g. if you'd want to run a Go script on a target host, the target needs to have Go installed by any mean, including installing it by one of your playbooks' tasks. But when you're running Salt Agentless

, basically you're deploying a tiny, miniature version of Salt on the target, and then telling this mini-Salt (via SSH) to "crunch" the state files it took with itself when it was deployed. Of course if you want, you can purge this temporary install, after tasks get finished.

Standard Ansible operation vs Salt Masterless.

Standard Ansible operation vs Salt Masterless.

As you can see, this may be called agent-less, but there's still some kind of burden on the target host - Salt still works on the target machine, not only on the Master itself. You might see this as a negative - but it's not a bug, it's a feature - Salt's remote execution is actually considered a key feature. Ansible doesn't have it (Technically, you could install Ansible on remote host using Ansible, and then order it via shell module to run an Ansible playbook... But come on, let's be real.), and it doesn't really care.


No wins or loses in this round - they're not worse or better, they're different. Keep those differences in mind when you'll be choosing which tool to go with.

Round Three - the syntax - FIGHT!

The syntax of those two tools usually looks very similar. Take a look:

A crude example of templating the banner file in Salt.

/etc/ssh/banner:
  file:
    - managed
    - user: root
    - group: root
    - mode: 400
    - source: salt://ssh/banner.jinja
    - template: jinja

A crude example of templating the banner file in Ansible.

- name: 'template -- banner'
  template:
    src: 'banner.j2'
    dest: '/etc/ssh/banner'
    owner: 'root'
    group: 'root'
    mode: '0400'

Unless you'd touch more complicated tasks, the syntax differences are negligible, except one detail - Salt is declarative, Ansible is procedural. Again, take a look at the examples above. The upper one looks like a thing you expect to accomplish with no guidelines on how to do it, the lower one looks rather like a direct order - "do this, that way"

You might have also noticed, that Salt expects you to provide a bit more information, whilst Ansible has modules built for limited purposes - so, for example, you won't have to define the templating engine as it's settled that "template = jinja".
This doesn't mean, that Salt is pesky or pedantic, it just has to ask you what do you want to do, because there are more options available.


Who's better? No one. Both use YAML

and Jinja, both are good. A great tandem of a powerful "not-markup-language" and a simple, yet extensible templating engine. Easy, understandable, and there's a lot of support for both tools when it comes to IDE extensions or plugins. For my favourite IDE - Visual Studio Code, there's a huge bunch of extensions available, providing snippets, syntax validation, formatting... Everything you'd want to have.


The conclusion? Don't mind the syntax, you'll enjoy it anyways, and the difficulty isn't really an issue here. Nothing you wouldn't be able to get comfortable with, after a little while.

Round Four - execution time - FIGHT!

And that's where finally some heavy blows happen. Ansible gets beaten, hard.

Let's be real - SSH is not Formula 1. It never was, and it will never be. This may not be a real issue, when you've got one tiny server under your command, but as your fleet gets bigger, you'll feel those minutes withering away. By default, Salt uses ZeroMQ

, which is blazing fast when compared to the traditional SSH connections. Salt can also leverage the persistence of minions, to cache things up - which adds even more rocket fuel straight to the already much faster process. The only downside is that you do have to set up the minions first - that won't tip the scales though.


If you want the faster thingy, for example when handling a large fleet of machines on a limited time budget - there's absolutely no comparison. Go Salt.

Round Five - extensibility - FIGHT!

Another hit on Ansible. Salt introduces the concept of so-called "Events and Reactors". In a nutshell, this means, that things happening on one Salt machine, can trigger things on another Salt machine to happen.

Basic graph of the events-reactor system.

Basic graph of the events-reactor system.

Ansible follows the list of tasks it was ordered to do, so if you'd want to trigger something based on another thing elsewhere, it's going to be a long and painful journey. If you'll be even able to reach something close, you still won't be able to squeeze out a smooth, continous response to real-time events. That's the price of simplicity.


On the other hand, Ansible won't miss its chance to pack a punch there - it has a lot of integrations for popular and exotic tools, software, platforms et cetera - the community modules allow you to easily operate on, for example, docker containers, a variety of AWS offerings, Kubernetes clusters, all kinds of databases... What surprised me, is that for example, for networking hardware from Cisco and Juniper, the support is provided by the vendors themselves. Everything works pretty much out of the box, the only thing you have to do, to enable such integration is to define that you want to use it in your playbook. Those can make automation easier, when it comes to things you'd normally have to manually set up in your Salt state.


The Ansible Galaxy

- repository of community roles and playbooks, is pretty large, and i mean large. Really.

Ansible Galaxy - there's a lot to go around.

Ansible Galaxy - there's a lot to go around.

You can easily browse, search, and compare different solutions to find the one you desire - just find what you've been looking for, check the reviews, grab the code - or if you're interested, you can also click one of the buttons to check out (If they were set up) the issue tracker of this particular role/playbook, the repository, website, docs. Salt also has a repository of "formulas" - but it does come in a form of a git repository list on GitHub. Another thing worth mentioning is that the Ansible Galaxy is pretty much free for all - you can just publish your stuff on the Galaxy, and the community can rate you on the basis of documentation quality, ease of use, promises vs results, production readiness..


Salt Formulas

are rather less... Open. Sure, you can apply to get your formula to the central collection, but the collection itself is much more curated, picky. And let's be honest, much, much smaller. Still a wide variety of different packages to check out, though!

SaltStack Formulas - A bit less to go around, but with additional quality assurance.

SaltStack Formulas - A bit less to go around, but with additional quality assurance.

Both tools can be really widely extended, as you see. The difference lies in the field of such extension. If you just want to get things easily done, Ansible, sure thing. If you want to get complicated scenarios going, and expect native support for their intricacies, Salt for the win.

Round Six - security - FIGHT!

And that's where things get really... Intricate. SSH is as secure, as you'll make it (A great opportunity to check out our article on securing SSH here, by the way!) so the basics of Ansible security are dependent on you, personally. If you'll do something stupid - such as sharing single key that isn't stashed like in fort Knox, between many machines. Leaking this key out means getting absolutely PWN'd. There are also a few additional things that you should take care of - obscuring the sensitive data in command output & logs, keeping secrets in a Vault... Overall though, when it comes to things that do not explicitly depend on your actions, the last known major CVE was present in versions lower than 2.2.1, which was ~2016, so it's ancient history by now

.

CVE list regarding Ansible (including Tower.) 5 in total.

CVE list regarding Ansible (including Tower.) 5 in total.

Salt's current architecture is much more secure on paper, as it leverages the ID's

and keys, where the key is unique for every Minion. The secrets are also stored on the Master, and sent out to Minions when they are required - which is nice, it's much easier to keep one secret Vault secure, than to keep multiple developers safe from human errors. There's also something called Job Cache, basically a registry of all executed tasks - which makes auditing quite enjoyable. Unfortunately, there's also a lot more of CVE's discovered, and the last major one found is from 27.02.2021 - a much more recent discovery, than you'd want to see.

First 12 CVE's from the list regarding Salt. There are 41 in total.

First 12 CVE's from the list regarding Salt. There are 41 in total.

Things are swiftly patched and fixed, of course - but a 2020 headline yelling "A critical Salt vulnerability affected thousands of data centers"

is not something you'd easily scrub out of your mind. And there's a lot more where that came from. About Ansible... Not so much. Barely any, actually. But, before you'll put on your tinfoil hat, and chase me screaming "RedHat COVERED IT ALL UP", let me tell you - nah, i don't think so. Nothing to be gained, not worth effort. Get your tinfoil back on the sandwitches it should enclose tightly, and let's wrap up this round.


I do trust both tools, you don't have to though. Keep in mind - in the world of information, trust is an expensive commodity, but it won't pay for your own mistakes. Those tools may have in-place security measures, but you're also an important puzzle piece - the most important, and the most susceptible to potential breach, actually. Do what you can, to gather additional layers of defense, spare a bit of time to make things more secure. Doesn't matter which tool you're using, when you've exposed the secrets you really shouldn't, does it?

Final Conclusion

No matter which one you've chose, it's a win. You do wish to automate things, many people still don't, but they absolutely should.

A well-deserved meme, if you've reached this far.

A well-deserved meme, if you've reached this far.

Both tools are briliant, extensively packed with great features, and extremely useful. As you've seen, both have their strong and weak points. Use this knowledge, to choose the right tool for your use-case, and your individual style. And don't be afraid to change this decision if you feel it's wrong - in Poland there's a saying, only a cow doesn't change it's mind. Tools are meant to help you, not to make things more difficult. When something doesn't suit you, just change it. That's my final advice.


Enjoy your journey, thank you for reading, and see you next time ;)

References