If you’ve been working in the IT industry over the last decade, you may have heard the name Ansible passed around. If you’re not sure what Ansible is and wanting to learn more then you’re in the right place.

Ansible is a popular, open source IT automation tool originally released in 2012 by Michael DeHaan and now owned by Red Hat. It’s widely used for automating many different IT tasks on remote devices including provisioning virtual machines, configuration changes, software installations, and more.

From a network engineering and automation perspective, Ansible can be used to interact with network devices to to perform actions like retrieve device information, manage and validate configurations, and ensure compliance.

Ansible has a lot of really awesome features, but here are some highlights:

1. Agentless Architecture

One feature truly making Ansible invaluable in the IT industry is its agentless architecture design. This means you don’t need to install software on managed clients. Instead, Ansible is installed on a server called a control node (the server Ansible is installed on) where it manages all managed nodes from a central location. It then uses common protocols like SSH and HTTPS to connect to devices to perform any required actions.

The control node is also horizontally scalable making it capable of managing tens of thousands of devices or more. Landon Holley and James Mighion gave a good presentation at the 2018 Red Hat Summit covering just that.

2. Idempotency

This very well may seem like a made-up term to many people, but it’s an important one to understand. Idempotency is a concept that means an operation will produce the same result regardless of how many times it’s executed.

Achieving idempotency is particularly important when working with network devices because if a device state were to change unintentionally while a new configuration in transit, it can devastating impacts on overall network stability.

3. Extendable

One of the great things about Ansible is how extendable it is. There is already a vast amount of modules publicly available for networking automation tasks to use. Existing modules include Cisco IOS-XR, Juniper, Palo Alto, and many more.

If you happen to need a specific functionality not included in the existing modules, you can write your own module to further extend Ansible. This modular approach makes the Ansible platform infinitely extendable to do just about anything which can be programmed.

Visit Ansible’s Network Modules page for a full list of current networking modules available.

4. Vendor Agnostic

If the extendibility didn’t get you, then perhaps this will. The modular approach to Ansible detaches it from any kind of vendor limitations allowing you to have mixed-vendor networks and the same functionality.

Further, if you utilize an Infrastructure as Code platform, you can create device configurations separate from any vendor specific specifications and Ansible will translate them whatever vendor config you need (with proper setup, of course).

5. Included in Cisco DevNet Certifications

Ansible is recognized by Cisco as an essential element of network automation. As such, they have included it into the Cisco DevNet certification exams at the Associate, Professional, and Expert levels.

Check out my post about the DevNet Associate if you’ve been considering taking the exam. Pursuing that certification can have very positive impacts on your career.

Ansible Components

Let’s take a brief look at the primary components used in Ansible:

Inventory Files

This is an important located in the root directory of your Ansible application. It defines what devices the software is aware of and any variables to be used for those devices such as IP addresses, connection protocols, etc. An inventory file can be written in either YAML or INI format.

Devices are identified by a name, often the hostname. You can further organize your devices into groups. One good example would be is if you have multiple sites with equipment, you could group devices by site.

Example inventory with variables:

router1 ansible_host=10.10.1.1
router2 ansible_host=10.15.1.2
switch1 ansible_host=10.10.1.2
switch2 ansible_host=10.15.1.3

[routers]
router1
router2

[switches]
switch1
switch2

There are ways to create a dynamic inventory, such as pulling information from a database, but that is outside the scope of this post.

Variable Files

Depending on the extent of your deployment, you may want to separate the variables from the inventory file and move them to dedicate variable files. There are two main categories:

• groupvars – Variables assigned to any device within the group
• hostvars – Variables assigned to specific devices

Variable file names must be the same as the group or host/device in order to work.

Modules

Modules provide the required functionality for Ansible to connect to and perform the desired commands or changes on a remote device.

Ansible modules are written in Python, but because of the vast amounts of existing modules to use you likely won’t have to actually code anything.

There are hundreds of modules publicly available already for everything from server management to network devices. If one of these modules doesn’t fit your needs however, you can create your own to extend Ansible as mentioned earlier.

Playbooks

Playbooks are the point of entry for all Ansible operations. In short, they are YAML files containing a list of instructions called tasks telling the server what to do.

Unfortunately, network automation isn’t automatic. You must first define what automation processes you need and the work that must be done to achieve them.

Here is a basic playbook that connects to a server, gets some information about it, and then prints it to the console:

The example playbook below connects to Cisco IOS devices, gathers information about them, and prints the information to the screen.

---
- name: Get router facts
  hosts: routers

  tasks:
  - name: Get facts from IOS devices
    ios_facts:
      gather_subset: all
	  
  - name: Print facts to console
    ansible.builtin.debug:
      var: ansible_facts

Further Reading

Ansible is a complex topic that can get extremely in depth, so it’s no surprise that there are additional components and concepts that are helpful to know even at the higher level. I didn’t include them in this post to avoid going into too much detail and creating an incomprehensible mush of words.

If you’d like to learn more, visit the Ansible for Network Automation documentation page and be sure to follow Tekyy on social media to get notifications about new posts about Ansible and other topics within networking and network automation.