Automation Tool Comparison

All configuration management tools mentioned here are idempotent. They can intelligently verify the current state of a device and only make a change if the current state does not match the desired state. For example, if you are pushing NTP servers and the device already has those NTP servers define, the tool will not re-apply the configuration.

Puppet

Created in 2005
Written in Ruby
Agent-based
- An agent needs to be installed on a system in order to manage it with Puppet
Uses the concept of a master node
Uses Ruby DSL for configuration instead of YAML like SaltStack and Ansible
Classes define common configuration, which are grouped into manifests which are the actual Puppet code pushed to a device. Manifests are grouped into a module.

Has support for NETCONF which negates the need for an agent on an IOS-XE device. This is a bit confusing because the textbook answer is that ”Puppet is agent-based.” However by supporting NETCONF, this makes Puppet angetless.

From Cisco documentation (linked below):

Puppet is a Configuration Management Tool (CMT) used for centralizing and automating configuration management. 
Traditionally, Puppet has used an agent-based architecture, requiring a software agent to be installed on the device 
being managed. However, Puppet now supports direct NETCONF integration to Cisco IOS XE devices.

Uses a pull model, where facts are periodically sent fromt he managed devices and config catalogs are pulled down from the master service to the device
Uses HTTP for transport

Chef

Written in Ruby
Agent-based
The instructions for a task is called a recipe
Uses Ruby DSL for configuration instead of YAML like SaltStack and Ansible
A collection of recipes comprises a cookbook
- There is a Cisco cookbook you can download and use to configure Cisco devices
Uses a pull-based model like Puppet

SaltStack

Created in 2011 as an alternative to Puppet and Chef
Written in Python
Supports both agent-based and agentless interactions
Uses YAML for configuration with Jinja templates
Has the concept of masters and minions. A master is the controlling node, but is not always needed. You can also do a multi-master setup for redundancy.
See https://github.com/ssplatt/salt101
Uses a push model, configuration is pushed to the devices
Uses SSH for transport

Ansible

Created in 2012 and acquired by Red Hat in 2015
Written in Python
Agentless
Configuration written in YAML domain specific language
The list of devices you manage via SSH/API is placed in an inventory
A playbook contains the tasks you run against managed devices.
Uses a push model

Puppet

Chef

SaltStack

Ansible

Further Reading/Watching