The previous two chapters incrementally introduced different ways to interact with the network devices. In Chapter 2, Low Level Network Device Interactions, we discussed Pexpect and Paramiko that manage an interactive session automatically. In Chapter 3, API and Intent-Driven Networking, we saw that networking is not just about individual devices, as it is a way for us to connect individual parts together, but our overall goal typically requires a higher business logic. For example, imagine this hierarchy of thought process from forming our business objective to actually perform an action on a networking device (with the top being close to the business logic): we looked at various APIs that provide a structured way of feedback from device as well as some well-defined command structure. Both of the methods are fairly low level, meaning they are focused on the individual device that we are performing our action on.

You wake up one morning and think to yourself that you have valuable information on your network, so you should put some secure measure around the network devices to make them more secure!

You then proceed to break the objective down into two actionable items to begin with:

• Upgrading the devices to the latest version of software, which requires:
  1. Uploading the image to the device.
  2. Telling the device to boot from the new image.
  3. We will proceed to reboot the device.
  4. Verify that the device is running with the new software image.
• Configuring the appropriate access control list on the networking devices, which includes the following:
  1. Constructing the access list on the device.
  2. Configuring the access list on the interface, which in most cases is under the interface configuration section to be applied to the interfaces.

Being an automation-minded Python engineer, you proceed to write the scripts using Pexpect, Paramiko, or API. But, as you can see, any network task represents a purpose with the actual execution at the tail end of the operation. For a long time, the engineer will translate the business logic into network commands, then we document them into standard operating procedures, so we can refer back to the process either for ourselves or our colleagues.

In this chapter and the next, we will start to discuss an open source automation tool called Ansible. It is a tool that can simplify the process of going from business logic to network commands. It can configure systems, deploy software, and orchestrate a combination of tasks. Ansible is written in Python and has emerged as one of the leading automation tools supported by network equipment vendors.

In this chapter, we will take a look at the following topics:

• A quick Ansible example
• The advantages of Ansible
• The Ansible architecture
• Ansible Cisco modules and examples
• Ansible Juniper modules and examples
• Ansible Arista modules and examples

At the time of writing this book, Ansible release 2.2 was compatible with Python 2.6 and 2.7 with a technical review for Python 3 support. However, just like Python, many of the useful features of Ansible come from the community-driven extension modules. After the core module is tested stable with Python 3 (hopefully in the near future), it will take some time to bring all the extension modules up from Python 2 to Python 3. For the rest of the book, we will use Python 2.7 with Ansible.

As one can tell from the previous chapters, I am a believer in learning by examples. Just like the underlying Python code for Ansible, the syntax for Ansible constructs are easy enough to understand even if you have not worked with Ansible before. If you have some experience with YAML or Jinja2, you will quickly draw the correlation between the syntax and the intended procedure. Let's take a look at an example first.