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

Further Reading/Watching

https://www.cisco.com/c/en/us/td/docs/iosxr/asr9000/app-hosting/b-application-hosting-configuration-guide-asr9000/b-application-hosting-configuration-guide-asr9000_chapter_0101.html

https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-xe/nb-06-cisco-ios-xe-faq-en.html#Puppet

https://www.youtube.com/watch?v=W7B-vjvkW0I&ab_channel=KevinWallaceTraining%2CLLC

https://dzone.com/articles/chef-101-getting-started-with-automation

https://www.gspann.com/resources/blogs/puppet-vs-chef-vs-ansible/

PreviousModel-Driven TelemetryNextNetflow

Last updated