Configuration Management Tools

Some configuration management tools require an agent. An agent is software that must be installed on
the system or device to be managed. This requirement could be a problem in a network automation
use because some network devices cannot support running agents and loading general software. In this
situation where the network devices do not support the agent, you can use a tool that supports proxy
agents or a tool that does not require agents at all.

There are two core types of configuration management tools with a third type that is usually a
derivation of an agent-based tool:

• Agent-based: This tool requires an agent to be installed on every device that the configuration
management tool will manage.

• Agentless: This tool does not require an installed agent on every device and it will communicate
through SSH or another given application programming interface (API) that the device supports.

• Proxy agent: This type of configuration does not require an agent on every device, but it does
require having some type of “process” or “worker” to communicate with the controller and managed
device.

Configuration management tools define target end states while allowing maximum flexibility to
automate one device or 10,000 devices. An example would be to ensure that your networking devices
are at their latest version.

When you describe what you want to automate in one of these tools, you often use a domain specific
language (DSL) or a structured markup language such as YAML.

A DSL is a language that is designed specifically to express solutions to problems in a particular domain.
In other words, DSLs are special-purpose computer languages and limited compared to a language like
Python or Ruby, which are general-purpose languages.
Some of the benefits of using these types of tools are fast implementation, lower failure rates,
shortened times between fixes, and, importantly, faster user adoption for nonprogrammers.

These tools can be used in a NetDevops CI/CD Pipeline to provide continuous deployment. Furthermore
using tools such as Ansible, make it easier to use to implement more advanced NetDevOps topics like
Infrastructure as Code (IaC), which declares the desired network state as code and uses a CI/CD pipeline
to automate the deployment of these changes. Configuration management tools are essential for the
automation of continuous deployment when working with a CI/CD pipeline.

From a networking perspective, it is common to deploy changes manually. This change could be adding
a VLAN across a data center or campus, or making daily changes to firewall policies for new applications
that are deployed. When there is a defined manual workflow to perform a set of tasks, proper tools
should be used to automate it. It does not make sense to spend an hour performing a change. This
change could take just a few minutes using a properly engineered tool. This process is where open-
source tools such as Puppet, Chef, Ansible, and SaltStack can dramatically reduce the number of manual
interactions with the network.

These tools are often referred to as DevOps tools. They are more specifically configuration management
and automation tools that are used by organizations that have implemented some form of DevOps
practices.

These tools enable you to automate application, infrastructure, and network deployments to a high
degree without the need to do manual programming. An example would be using a language like
Python. These tools reduce the time that it takes to perform certain tasks and they also offer greater
predictability.

Configuration Management for Networking

Puppet was created in 2005 and has been in use the longest compared to Chef and Ansible. Puppet
manages systems in a declarative manner, meaning you define the state that the target system should
be in without worrying about how it happens. In reality, that approach is true for all these tools. Puppet
is written in Ruby and refers to its automation instruction set as Puppet manifests. The main point to
realize is that Puppet is agent-based.

Agent-based means that a software agent must be installed on all devices that you want to manage with
Puppet. Examples include servers, routers, switches, firewalls, and the like. It is often not possible to
load an agent on many network devices. This procedure limits the number of devices that can be used
with a new Puppet package. By a new Puppet package, you can infer that it is possible to have proxy
devices when using Puppet. However, this process means that using Puppet has a greater barrier to
entry when getting started.

Chef, another popular configuration management tool, follows much of the same model as Puppet. Chef
is based in Ruby, uses a declarative model, is agent-based, and refers to the Chef automation instruction
as recipes (grouped, they are called cookbooks).

It is often difficult to load agents onto machines to automate them. When it is technically possible, it
often increases the time that necessary to get the solution or tool deployed. Ansible was created as an
alternative to Puppet and Chef. Ansible was later acquired by Red Hat in 2015 and Red Hat was most
recently acquired by IBM. The two notable differences between Puppet, Chef, and Ansible are that
Ansible is written in Python and that it is agentless. Being natively agentless significantly lowers the
barrier to entry from an automation perspective. Since Ansible is agentless, it can integrate and
automate a device using an API. For example, integrations can use Representational State Transfer
(REST) APIs, Network Configuration Protocol (NETCONF), SSH, or even SNMP, if desired. Playbooks are
Ansible sets of tasks (instructions) used to automate devices. Each playbook consists of one or more
plays, each of which consists of individual tasks.

It is worth noting that each of these tools had their start in automation for applications and cloud
infrastructure. It was not until after each project and company had a significant amount of traction that
the companies started to include network automation into their portfolios. With Ansible, a set of
automated tasks is called a playbook.

Salt, by SaltStack, is another configuration agent-based management and orchestration tool similar
to Puppet and Chef. It requires each Salt-managed node to have a salt minion service installed. Usually,
this approach is not a blocker on a server, but in the networking world, it is not possible to install custom
software on the network equipment that you want to manage. To solve this problem with Salt, you can
use the proxy minion, which is based from a minion that does not need to be installed on the targeted
device and can run ubiquitously. In other words, proxy minions run intermediate software that mediates
between the salt master and the salt minion. It is written in Python and it uses a message queue-based
system (zeroMQ) to push commands and configuration to minions and allows for publish and subscribe
messaging.

Cisco supports all the tools that are mentioned, but currently has the most support across platforms
with Ansible, largely due to the ease of extensibility and agentless functionality that Ansible offers.
Cisco Ansible Integrations

Ansible ships with thousands of new modules. You can refer to these modules as the “module library.”
These modules can be executed directly through the creation and execution of Ansible playbooks. In this
subtopic, you will explore Cisco modules and learn how to view details about them through the online
Ansible documentation.

Cisco product families with support for Ansible:

Ansible Cisco Modules:

• Cisco Application Centric Infrastructure (ACI)

• Cisco AireOS

• Cisco IOS Software

• Cisco IOS XR Software

• Cisco Meraki

• Cisco Network Services Orchestrator (NSO)

• Cisco Nexus Operating System (Cisco NX-OS)

• Cisco Unified Computing System (Cisco UCS)

• Cisco ASA adaptive security appliance

One of the great benefits of Ansible is that it can be used in a multidomain environment. You can use it
to automate campus LANs, data centers, clouds, service providers, and virtual networking environments.
Users can also write their own modules. These modules can control system resources, packages,
services or files, or manage execution of system commands or API calls. You can also create custom
modules, if needed, for old devices that may only support Telnet or SNMP.

For a list of all available modules, you can navigate to the module index from https://docs.ansible.com