6.6 Recognize the capabilities of configuration management mechanisms Puppet, Chef, and Ansible

6.6 Recognize the capabilities of configuration management mechanisms Puppet, Chef, and Ansible

Why do we need configuration management?  When we first set up our network, we have something called a baseline.  The baseline is the standard configuration for our network.  Every device configuration should follow the baseline. 

Later, if an administrator makes a change to a network device, it must be documented.  We don’t want to introduce undocumented changes because it will become difficult to troubleshoot the network, we will introduce potential security risks, and make the network inefficient.

The problem is that when manually change the configuration of a device, we have no way to automatically track the change.  If I console into a router and change the speed or interface on a port or modify an ACL, there is no documentation of this change. 

Nobody knows what was changed, who changed it, when it was changed, or why.  The solution is to centralize the configuration of each device.  A simple solution is to store the configuration in plain text on a server or shared folder.  But can we trust the configuration files in the shared folder?  What happens if we manually update the configuration on a device but forget to update the configuration in the server?

For example, say I install a new router and configure the interfaces.  We save this configuration on our server as a baseline.  A few months later, our internet connection changes and I update the static IP address on one of the interfaces.  A few months after that, the router malfunctions and needs to be replaced.  The administrator who replaces the router downloads the original configuration and configures the router, but it doesn’t work.  Why not?  The original configuration doesn’t contain the correct interface settings.  The administrator spends several hours troubleshooting the connection with the ISP.

A better approach is to use a configuration management tool.  The tool keeps track of each configuration file, the changes made, when the changes were made, who made them, and why.  The configuration management tool keeps copies of the older versions of each configuration, so that we can go back in time and compare different versions of the file.

We should make the changes to the file in the configuration management tool, and let the tool use the file to update the configuration on the device.

We also use the configuration management tool to regularly check the configuration on each device to ensure that it hasn’t changed.  This is known as configuration monitoring.  Even with a configuration management tool, it is still possible for an administrator to manually change a device’s configuration or for the configuration to become corrupted.

Configuration provisioning is the concept of making the changes after the configuration file has been edited.  We should be able to

• Choose the number and type of devices whose configurations will be updated.  We could update all devices, or a subset of devices such as switches, or switches of a certain model, or switches in a specific location.
• We should be able to revert to an older configuration if the new one causes undesired operations.
• We should be able to validate the change to ensure that it will work as expected before we implement it.  This might involve a simulation, or at least a verification of the logic or syntax in the configuration.
• We should be able to verify that the change was made correctly.
• We should be able to choose whether the change is made to the running-config or both the running-config and startup-config.
• We should be able to create templates for different device configurations, such as a standard switch configuration or a standard router configuration.
• We should be able to schedule a configuration change.  For example, we might schedule a configuration change for after hours.

The template helps us configure devices quickly.  It also reduces errors associated with manual configuration.  If we have a standard configuration, we can replace the names and other parameters with variables.  We can use an application to generate a configuration for a new device by entering some values.

Ansible is a tool that allows us to create configuration templates.  Here is part of my router configuration

I could create a template out of this configuration and then use it to configure many other routers.  I have replaced the variable portions of my configuration with actual variables, which are surrounded by curly braces.

If I plug the following variables into my Ansible script, it automatically uses them and the template to generate a configuration file.

hostname
IP address IF1
subnet mask IF1
IP address IF2
subnet mask IF2
duplex 2
speed 2
IP address IF3
subnet mask IF3
duplex 3
speed 3

The template helps me focus on configuring the device by specifying the necessary parameters.  It makes sure that I don’t miss any fields.  If I forget something, I won’t be able to save the configuration.

If many devices use a common template, and I make changes to the template, I can use the software to automatically update all the devices that use the same template.  For example, I could use the template to change the enable password on all my switches at the same time.

Ansible is open source and available for free.  It requires us to create several files

• A Playbook is a file that lists actions Ansible should perform
• The Inventory lists the hostnames of all the devices we have, as well as the role that each one performs
• Templates are templates of the configuration without the details
• Variables list the data that Ansible will substitute into the template

After we create a configuration, Ansible uses SSH or NETCONF to update the device configuration.  Ansible “pushes” the device configuration to each network appliance.  When Ansible configures a device over SSH, it is doing so exactly like a human user.  Ansible uses SSH when a device can’t be configured via NETCONF.

Ansible can also monitor each device to ensure that its configuration has been successfully updated.  Ansible uses the playbook to determine how to respond when it detects a device with the wrong configuration.  It can either notify the administrator or update the configuration automatically.

The second tool we will learn about is called Puppet.  Puppet is also open source and available for free.  Once we install Puppet, we create several files

• Manifest.  The manifest tells Puppet how we would like a device to be configured.  Inside the Manifest is a Resource, a Class, and a Module, which are distributed as a hierarchy of configurations.  Each module contains several classes, and each class contains several resources.
• Templates.  Puppet uses a template and variables to generate a Manifest.

Unlike Ansible, we use the Manifest to tell Puppet what the device configuration must look like in the end.  Puppet figures out what steps it must take to configure the device.

Puppet must install an “agent”, or software application on each device that requires configuration.  Puppet communicates with the agent, and the agent configures the device.  Some versions of Cisco IOS do not support Puppet. 

If a Cisco device doesn’t support Puppet, Puppet can configure the device over SSH.  It must install an External Agent on another device and let the other device connect to the Cisco device over SSH.

Puppet makes changes through a Pull mechanism.  We create the Manifest and Template files on the Puppet server.  We also install the Puppet agent on each device.  The agent regularly checks the server for updates to the configuration, and “pulls” the manifest and other data from the server so that it can understand how to configure the device.  The agent (and not the server) updates the device configuration.

In other words, every device with a Puppet agent is asking the Puppet server “is my configuration correct or do I need to make some changes?”.

The third tool is called Chef Automate (better known as Chef), which operates like Puppet.  We create several files

• Resource.  The resource is a set of objects that Chef must manage.  It is like a list of ingredients in a recipe book – ingredients that can be used in multiple recipes.
• Recipe.  A recipe is a set of instructions that can be applied to a resource.  It tells us how to modify a resource.
• Cookbooks.  A cookbook is a group of recipes that are related.  We group recipes so that we can manage them better.
• Runlist.  A runlist is a set of recipes that can be run against a device.  Chef runs the recipes in the order that they appear on the list.

Chef installs an agent on each device and pulls configuration data from the server as required.  It also pulls the necessary recipes and resources so that it can keep the device updated.  Chef is not supported on many devices. Puppet and Chef use HTTP and a REST API to communicate between the server and the agent.