Introduction to Ansible

In this lesson we’re going to be taking a look at an overview of Ansible and the power it provides in allowing us to automate our networks.

Overview

Ansible is a free and open-source automation engine developed by Red Hat. We can use the power of Ansible in CLI completely free with absolutely no limitations. Instead, Ansible offers a paid version known as Ansible Tower that offers a GUI front end and premium support.

Ansible assists with:

  • Configuration management
  • Application deployment
  • Task automation

The great thing about Ansible is that it doesn’t require an agent to be installed on the device we’re managing. Instead, Ansible utilises SSH to manage and configure our devices.
As such, as long as SSH is configured on our devices – they can be managed by Ansible.

To show you the power than Ansible offers, let’s take a look an example.

Ansible Topology Example

Lets say we want to check which interfaces are up on the four switches above. Can you imagine having to manually connect to each device and run a show ip interface brief on each? It would be very time consuming.

Alternatively, imagine if we needed to amend an ACL on the switches to allow an addition subnet to remotely access the devices. We can do this manually, however we’d have to enter the configuration manually on each device.

What happens if we make a mistake? How do we know the configuration will be added consistently across all the devices?

Ansible allows us to push consistent configuration to all of our devices at one in seconds.

Can you imagine how much time and effort this would save when we start to use Ansible to configure all of our networking devices?

There’s two methods of utilising Ansible:

  • Ad-hoc
  • Playbooks

To provide some context, ad-hoc commands are used for one off quick tasks. Lets say we want to export a show interface description from our devices. It would be quicker to run this as an ad-hoc command rather than creating a YAML script (Playbook).

Playbooks on the other hand contain a list of tasks we want to complete on our devices. The playbooks themselves are written in YAML format which is a human readable markup language – similar to XML. Using playbooks is where the real power of Ansible is obtained.

We’ll be looking at both methods in more detail in the upcoming lessons.

Components

There are a number of components that allow Ansible to work.

Let’s take a look at an overview below, we’ll go into more depth in later lessons.

Inventory

The inventory file (also known as the hosts file) within Ansible is used to list and define the devices we want Ansible to manage.

In order for Ansible to manage a device, it must exist within the inventory file which must be saved in INI or YAML format.

Ansible installs a default inventory named hosts which is located here:

 /etc/ansible/hosts

Ansible Configuration File

This file contains the configuration for Ansible. The configuration specified within the file controls the behaviour of Ansible within an INI file. can include:

  • Location of inventory file
  • Ignore SSH keys on devices
  • Retry count
  • SSH port

Modules

Modules are units of code within Ansible that are used to execute our tasks. We can use modules for both ad hoc commands and playbooks.

An Ansible module is a block of python code deep down. Depending on the tasks required, there are a number of modules available:

  • raw (execute low-down and dirty SSH commands)
  • ios_command (run commands on IOS devices)
  • ios_config (apply configuration to IOS devices)
  • asa_command (run commands on Cisco ASAs)