Ansible for Network Engineers

 

Automate your network infrastructure with Ansible | @fatosi

 

Ansible is an open-source automation tool written in Python that has emerged to be one of the leading automation tools. It can be used to deploy configurations, software and orchestrate a combination of tasks. Ansible provides a way to manage infrastructure at scale.

Using Ansible, a network engineer can describe the state of the infrastructure in a fashion called "infrastructure as code". Moreover, Ansible enjoys vast support of network equipment vendors and has a very vibrant open-source community.

Ansible is rapidly being adopted by infrastructure engineers and developers to automate basic tasks because of its ease of use, it also requires minimal time and effort to set up. You can quickly turn your Linux based laptop into an Ansible control server by running a few commands on your terminal:

 

  $ sudo apt-get install software-properties-common
  $ sudo apt-add-repository ppa:ansible/ansible
  $ sudo apt-get update
  $ sudo apt-get install ansible
      	

 

You can then quickly confirm that it has been successfully installed:

 

  $ ansible --version
  ansible 2.8.5
  config file = /etc/ansible/ansible.cfg
  python version = 3.6.8 (default, Oct 7 2019, 12:59:55) [GCC 8.3.0]

 

Why Ansible for Network Engineers?

Before we even dive deeper into the Ansible architecture and how to start using it in your network environment, let's deliberate on why network engineers should embrace Ansible.

This is an excerpt from the report "Network Automation with Ansible," by Jason Edelman.

Over the past 5+ years, the network industry has seen many new trends emerge, many of which are categorized as software-defined networking (SDN).

SDN is a new approach to building, managing, operating, and deploying networks. The original definition for SDN was that there needed to be a physical separation of the control plane from the data (packet forwarding) plane, and the decoupled control plane must control several devices.

Nowadays, many more technologies get put under the SDN umbrella, including controller-based networks, APIs on network devices, network automation, whitebox switches, policy networking, Network Functions Virtualization (NFV), and the list goes on.

One of these trends is the emergence of application programming interfaces (APIs) on network devices as a way to manage and operate these devices and truly offer machine to machine communication.

APIs simplify the development process when it comes to automation and building network applications, providing more structure on how data is modeled.

For example, when API-enabled devices return data in JSON/XML, it is structured and easier to work with as compared to CLI-only devices that return raw text that then needs to be manually parsed.

Simple to Use

One of the most attractive attributes of Ansible is that you DO NOT need any special coding skills in order to get started. All instructions, or tasks to be automated, are documented in a standard, human-readable data format that anyone can understand.

It is not uncommon to have Ansible installed and automating tasks in under 30 minutes!

For example, the following task from an Ansible playbook is used to ensure a VLAN exists on a Cisco Nexus switch:

  - nxos_vlan: vlan_id=100 name=web_vlan

 

You can tell by looking at this almost exactly what it’s going to do without understanding or writing any code!

Extensible

Ansible is also extremely extensible. As open-source and code start to play a larger role in the network industry, having platforms that are extensible is a must.

This means that if the vendor or community doesn’t provide a particular feature or function, the open-source community, end-user, customer, consultant, or anyone else can extend Ansible to enable a given set of functionality.

In the past, the network vendor or tool vendor was on the hook to provide the new plug-ins and integrations. Imagine using an automation platform like Ansible, and your network vendor of choice releases a new feature that you really need automated.

While the network vendor or Ansible could, in theory, release the new plug-in to automate that particular feature, the great thing is, anyone from your internal engineers to your value-added reseller (VARs) or consultant could now provide these integrations.

It is a fact that Ansible is extremely extensible because as stated, Ansible was initially built to automate applications and systems. It is because of Ansible’s extensibility that Ansible integrations have been written for network vendors, including but not limited to Cisco, Arista, Juniper, F5, HP, A10, Cumulus, and Palo Alto Networks.

 

Agentless

The importance of an agentless architecture cannot be stressed enough when it comes to network automation, especially as it pertains to automating existing devices.

If we take a look at all devices currently installed at various parts of the network, from the DMZ and campus, to the branch and data center, the lion’s share of devices do NOT have a modern device API.

While having an API makes things so much simpler from an automation perspective, an agentless platform like Ansible makes it possible to automate and manage those legacy (traditional) devices, for example, CLI-based devices, making it a tool that can be used in any network environment.

These solutions all simplify the management of networks, as they allow an administrator to start to migrate from box-by-box management to network-wide, single-system management. While this is a great step in the right direction, these solutions still don’t eliminate the risks for human error during change windows.

For example, rather than configure N switches, you may need to configure a single GUI that could take just as long in order to make the required configuration change—it may even be more complex, because after all, who prefers a GUI over a CLI! Additionally, you may possibly have different types of SDN solutions deployed per application, network, region, or data center.

The need to automate networks, for configuration management, monitoring, and data collection, does not go away as the industry begins migrating to controller-based network architectures.

As most software-defined networks are deployed with a controller, nearly all controllers expose a modern REST API. And because Ansible has an agentless architecture, it makes it extremely simple to automate not only legacy devices that may not have an API but also software-defined networking solutions via REST APIs, all without requiring any additional software (agents) on the endpoints.

The net result is being able to automate any type of device using Ansible with or without an API.

 

The Ansible Architecture and Modes of Operation

Ansible Playbooks:

Ansible uses a simple domain-specific language called YAML to design automation workflows. The language is as straight forward as seen in the figure above.

A workflow is developed using playbooks that can be modularized, much like software. A playbook comprises of tasks and plays.

A task is an action meant to be executed on remote devices (hosts). A play is comprised of tasks and the target remote devices. Subsequently, multiple plays make up a playbook.

Ansible orchestrates changes to production networks using playbooks that run sequential tasks as demonstrated below.

Inventory File:

The inventory file is a simple, plain-text file where you can specify and group hosts in your infrastructure.

By default, Ansible looks at the /etc/ansible/hosts file for hosts specified in your playbook. With this approach, you will have to define your remote systems in Ansible hosts file (/etc/ansible/hosts).

You can also categorize your hosts into groups based on whether similar tasks are to be executed against all remote hosts defined under the different groups.

Configuration File:

Ansible uses a configuration file to control the Ansible tool. Below is a simple configuration file.

 

   # override certain global settings
   [defaults]
   # default to inventory file of ./hosts
   inventory = ./hosts
   # disable host checking to automatically add hosts to known_hosts
   host_key_checking = False
 

This configuration file contains a couple of key-value pairs that override the Ansible default behavior. First, inventory changes the default directory of the inventory file. In the above example, the inventory file resides in your local directory and must be named hosts. You can edit the Ansible hosts configuration file using a text editor e.g nano or vim as below:

sudo nano /etc/ansible/hosts

Here is a simple inventory/hosts file with Datacenter and Campus groups:
 [Datacenter]
  192.168.33.10
  192.154.20.35
 [Campus]
  192.168.10.24

 There are numerous approaches to configuring the Ansible tool to meet the needs of engineers working in different environments. You can find more configuration options here.

Remote Hosts Authentication:

Ansible uses SSH primarily for transport. Given that, you must have a way to handle authentication. By default, Ansible assumes engineers use SSH keys instead of usernames and passwords for authentication.

This enables engineers to access hosts without typing out passwords every time playbooks are run. If needed, this default behavior can be overridden.

Normally, when installing Ansible using a package manager like yum or apt the inventory file and configuration files reside in the /etc/ansible directory. Additionally, by setting host_key_checking to False,we will not be prompted to add the hosts to the known_hosts SSH file.

You can configure key-based ssh access for the remote Ansible hosts by first generating an ssh key pair on your Ansible control server:

ssh-keygen

Then copy the public key to all your remote hosts you need to connect to via the ssh key:
   
ssh-copy-id -i ~/.ssh/id_rsa.pub ssh_user@remote_host

 

Variables:

Each of the network devices is different. They have different hostnames, IP addresses, etc. Because our devices are not exactly alike, we need to accommodate the differences via variables. Variables allow for a standard set of plays while still accommodating these differences.

Variables can either be defined in the Playbook or the inventory file. To reference a variable, you use the Jinja2 templating system convention of the double curly bracket. You can also optionally specify host and group variables in the inventory file.

Single Host Variables Configuration

One can define settings for a specific host using files with the same name as the host eg: Datacenter-host1 under the host_vars directory. 

   sudo mkdir /etc/ansible/host_vars
   sudo nano /etc/ansible/host_vars/Datacenter-host1 

You could then add SSH settings to this file for the Datacenter-host1. 

   ansible_ssh_host: 192.168.33.10
   ansible_ssh_user: root
   ansible_ssh_port: 22 

Group Variables Configuration

One can also configure common variable settings of a Group of hosts using a file with the same name as the group name eg: Campus under group_vars directory.

   sudo mkdir /etc/ansible/group_vars
   sudo nano /etc/ansible/group_vars/Campus
 

You could then add the common variables to this file used by all the hosts added under this group.

   ansible_ssh_port: 22
   ansible_ssh_user: root
 

Templates:

In many operations, a network engineer typically provisions a new device by copy-pasting an old set of configurations into the new device while replacing variables such as the hostname and IP addresses. Ansible standardizes such using Jinja2 templates.

Jinja is a templating language that can greatly aid in the roll-out of new network devices. Jinja can be used with Ansible to quickly generate config files based on your custom templates and build an automation workflow while ensuring that config files are properly built based upon predefined standards.

This also helps enhance standardization across your entire infrastructure, which is a critical requirement for successfully deploying automation in your infrastructure.

   interface {{ interface.name }}
   description {{ interface.description }}
   {% if interface.uplink %}
      switchport mode trunk
   {% else %}
      switchport access vlan {{ interface.vlan }}
      switchport mode access
   {% end if %}
 

With the above template, I have basically dictated that if the uplink property of an interface is True, then the interface is set as a VLAN trunk. Otherwise, it’s set up with the appropriate access mode!

Ansible Modules:

Ansible ships with a number of modules that can be executed directly on remote hosts or through Playbooks. Ansible modules are Python code executed on the remote hosts by default. Users can also write their own modules.

These modules can control system resources and handle executing system commands. To learn more about available network modules and their usage, check out the Ansible site

In part 2 of this article, we will go through a practical hands-on lab to demonstrate a real-world application of the Ansible automation framework to programmatically manage network devices!