Ansible vs Salt

Posted by UpGuard

Ansible vs. Salt

The sysadmin or devops pro of today typically needs to manage a large numbers of servers, often automating some tasks or performing the same action several times over, like installing and provisioning a new server, rebooting a set of servers at specific times every day, deploying the same package to a group of servers, and so on. For such busy folks, Configuration Management (CM) tools like Ansible and Salt are absolute lifesavers.

Up to around 2011, the CM market had been dominated by 2 main players – Puppet and Chef. They are still the market leaders, but some new upstarts have ensured the originators don’t have it all their own way. Two up and comers are Ansible and Salt. They have both been developed in Python, and one of their major raison d’etre was a lingering dissatisfaction on their founders’ parts with the performance and execution of the big boys Puppet and Chef.

The Details: Ansible

Ansible is much more spiritually similar to Salt than to either Puppet or Chef. The focus of Ansible is to be streamlined and fast, and to require no agent installation and no dependencies on the machine to be managed, except for a Python interpreter. The parent sponsor company - previously called AnsibleWorks, now just Ansible - is laser focused on deployment speed and simplicity. Thus, Ansible performs all functions over either standard SSH or the Paramiko module which provides a Python interface to SSH2, and for those OS’s in which SSH is blocked by default for root, Ansible can ‘sudo’ to emulate root user access. Ansible configuration and commands are executed via YAML syntax in configuration files called playbooks, and you can organize and store playbooks into templates or packages for future distribution and reuse; there are already many shared templates online through their Galaxy website. Oh, and Ansible modules can be written in any language that can output JSON modules. The Python base was chosen as an alternative to Puppet/ Chef’s Ruby, as it is usually pre- installed in most Linux distress today.

Which is better, Salt or Chef?

The Details: Salt

Salt, like Ansible, is developed in Python. It was also developed in response to dissatisfaction with the Puppet/ Chef hegemony, especially their slow speed of deployment and restricting users to Ruby. Salt is sort of halfway between Puppet and Ansible – it supports Python, but also forces users to write all CLI commands in either Python, or the custom DSL called PyDSL. It uses a master server and deployed agents called minions to control and communicate with the target servers, but this is implemented using the ZeroMq messaging lib at the transport layer, which makes it a few orders of magnitude faster than Puppet/ Chef. Salt's biggest advantage is its scalability and resiliency. You can have multiple levels of masters in a tiered arrangement that both distributes load and increases redundancy. Salt also uses YAML config files, organized into templates or packages called states.

Now the 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. 


You really cannot go wrong when choosing either of these tools. For a sysadmin or devops professional, they sure beat the alternative – mind-numbing repetition and tedious manual server config. These tools both have a learning curve before you master them, but the payoff is sweet indeed. So which one to choose? Again, let’s first stress that here, you are a billionaire choosing between a Learjet or Gulfstream private jets –either choice will make your life much easier, and be thankful that you live in a world that offers such a rich choice! That said, Ansible seems to have a slight edge compared to Salt, mainly because of the ‘any programming language’ ability and its slightly better security. The bigger question, however, is in comparison to the big daddy of the CM world – Puppet. See below for a comparison summary. What other pros/cons would you add to the list? We'd love to hear your comments.


  Pros Cons
  • Agent-less deployment and communication

  • CLI supports almost any programming language

  • Uses Python, which is omnipresent in Linux distros

  • Excellent security using SSH / SSH2

  • Additional Tower dashboard allows for visual management of nodes/resources (available in commercial version)
  • Prone to performance issues at times
  • Introspection (i.e., seeing Playbook variable values) is lacking
  • Quickly scalable, very resilient and efficient because of multi-master capability

  • Use of minions offers more options and flexibility than Ansible

  • No GUI yet (currently under development)
  • Forces users to learn Python or PyDSL

  • Underdeveloped GUI

  • Minions not as efficient as agent-less communication for small-scale deployment

Learn more about the complete DevOps toolchain here... 

Free DevOps Toolchain eBook



More Articles

MySQL vs. MongoDB

MySQL and MongoDB represent two sides of an argument that has been raging recently concerning data storage – the tried and tested relational database vs. non-relational or NoSQL database.
Read Article >

Puppet vs. Chef Revisited

So, Puppet or Chef? They both have evolved significantly since we covered them last—suffice to say, we’re long overdue in revisiting these two heavy-hitters.
Read Article >

Python vs. Ruby

Python and Ruby are two of the best examples of the new generation of high-level languages which focus on simplicity and giving the programmer the ability to get things done fast, rather than syntax correctness and strict hierarchy.
Read Article >


Topics: configuration management, ansible, salt

UpGuard customers