In this article, I present a feature-driven comparison overview of four IT Infrastructure Automation (DevOps) tools: Ansible, Chef, Puppet and SaltStack. Without further ado, here it is:
Some of the features mentioned above need no further explanation, but some do: let’s dig a bit deeper.
Database
Both Chef and Puppet require a specific database in their architecture: PostgreSQL (Chef) and PuppetDB (Puppet). The advantage of using a database is that all configuration files are stored centrally, which allows for – among other things – separate backup of these files. The disadvantage is that performance and scalability of the entire solution is impacted by an additional component: the database. Chef, for example, warns not to store the data on network storage, because of potential performance problems. Next to this, a database requires additional (specialized) maintenance. On the other hand, the best practice for storing playbooks in Ansible basically is a specific directory layout, which might not suffice either. The enterprise version of Ansible (Tower) does require PostgreSQL, but also MongoDB for a High Availability architecture.
Transport
All the tools in the overview use their own way of transport (which in this case means getting the configuration from master to node). Ansible uses a secure shell (SSH, Linux) or Powershell (Windows) to transfer configuration, which means that theoretically any device that can run a form or version of SSH can be controlled by Ansible. The other three tools use a specific message broker. Marionette Collective (or mCollective) was built specifically for Puppet.
Master
Ansible has the widest range of master support: the master or server software is supported on IBM AIX, BSD, Linux, MacOSX and Solaris, even though theoretically it could run on any operating system that supports Python 2.6 or 2.7 (3.5 support in tech preview). SaltStack runs on Linux and BSD, whereas Puppet and Chef run on Linux (RHEL, SLES and Ubuntu in their latest versions) only.
Agents
Ansible supports the widest range of agents: as stated above, as long as a client or device can run a secure shell (or Powershell), it can be controlled by Ansible. Of course, control software (in the form of modules) for such a device needs to be available, or written from scratch. On the networking front, apart from supporting traditional Linux based operating systems in such devices, it also supports Cisco IOS and Juniper JunOS natively. The three other tools use their own proprietary agents, but such agents are available for all common computing platform. Some network equipment is also supported: in SaltStack, a proxy-based configuration allows for controlling a network device which has no supported client. Puppet requires its enterprise version for controlling network devices (such as Cisco NX-OS), whereas Chef allows the open source version of its software to do the same.
Agentless
Of the four tools, Ansible is the one working completely agentless. It is possible, however, to use SaltStack in agentless mode as well. This requires SSH and Python on the remote machine. According to SaltStack, this is substantially slower than administration over ZeroMQ (even though no proof is supplied).
Public Cloud
Two out of four tools offer a Public Cloud version of their software: Ansible has a version on Amazon, whereas Chef has a version for Amazon, Azure and a proprietary cloud hosted by themselves. This of course does not mean that Puppet and SaltStack cannot be hosted in a Public Cloud.
Cloud management
All four tools offer a form of Cloud management, which means it is possible to use the tool to manage for example Cloud compute nodes. The approach differs: Ansible offers connectivity to Amazon, Azure, Google Cloud Platform and OpenStack. Puppet offers connectivity to Amazon, Azure, Google Cloud Platform and VMWare. Both Chef and SaltStack offer proprietary Cloud drivers which enables the configuration of various Clouds.
Step by step
Of the four tools, Ansible and Chef use a step-by-step deployment method. Step-by-step in this context means that the actions defined in an Ansible Playbook or Chef Cookbook are executed line by line, in a so-called procedural configuration. Puppet and SaltStack use a declarative configuration, which means the end-result is defined once and it is up to the tool to figure out the best way to reach this result.