Ansible Basics

A few weeks ago, I posted a blog about Infrastructure As Code, in this blog I will go a little deeper into Ansible and how to create a simple playbook. There are plenty of sites that have guides on how to install Ansible which you will need to do, one benefit of the install is that you pick up some Linux skills which you will build over time as you use Ansible more.

This blog will mainly focus on the network side of Ansible, so I would recommend setting up a virtual environment rather that installing and testing on production environments. Tools like EVE-NG, Cisco VIRL and GNS3 work well but I would probably recommend EVE-NG but it’s more personal preference. You could also just use VMware a build virtual routers and firewalls, most vendors have free trial licensing as well.

Once Ansible is installed, I would modify the ansible.cfg file with a Linux text editor like vi,vim or nano, the line you are wanting to change is “host_key_checking = False” with no # on the line save then exit. Next from Ansible server, ping each of the devices management IP’s then try to SSH to them, this will prompt you to accept the SSH key, if you can’t ping or ssh then diagnose and fix.

You will need to add the network devices into the Ansible host file (also called “inventory” file), again with vi or nano edit the host file with “nano /etc/ansible/hosts”, there is a format to adding hosts, if you are wanting to know more, I would recommend researching “ansible host file”, especially YouTube which have some great tutorials. My examples below show the required format. Note, the hosts file comes prepopulated with examples and entries, just add your new devices to the next new line.

Single Objects

Group Object

Ansible will need to know some information on the devices, such as OS, username, password and connection type. Since this is a lab environment, we will just add this into the hosts file with the password unencrypted but would not recommend this for production. The “vars” is short for variable, which is just a value that Ansible can use. Notice I that I’m using the group I created in the above step of “dev_switches”. The ansible_network_os value will be the OS of the device, eg Cisco is “ios”, Juniper is “junos” and Fortigate is “fortios". The ansible_connection is telling Ansible to use netconf API commands, Cisco IOS devices are mostly network_cli and Fortigate “httpapi”.

So now Ansible has that required information to connect to the devices, next we will create a simple playbook which are like scripts in that it’s just a set of instructions for Ansible to carry out. Playbooks are written in a format called YAML, I would recommend doing some research on this format as it’s important for building playbooks. For the first playbook, we will create a file in /etc/ansible named “change_hostname.yaml” which will change the hostnames to the names we defined in the hosts file. The text starting with < are my comments which would need to be removed if used.

First is the spacing, YAML is spacing sensitive so all spacing must be correct for YAML/Ansible to work. Notice that “- name:” and “junos_system:” are on the same spacing but the “hostname:” is indented by 2 spaces, this is the required format, also sub parameters also need x2 spacing. Next is the module usage, you will need to lookup the required module needed to carryout the required task, this can be found HERE, in this case I used “junos_system”. When on the Ansible modules page, ensure that you select the “2.9” version and not “Latest” and if you are using a certain parameter that has the “required” then it must be defined. Lastly is the “{{ inventory_hostname }}”, this is a builtin variable and is telling Ansible to use the hosts file entries, which we created earlier being “dev_switch01” and “dev_switch02”, Ansible knows to look in the hosts file for the hostname.

Next we run our playbook which shows the successful changes of the hostnames.

If you don’t come from a programming background the learning curve can be steep for Ansible, but like anything the more you practice the better you get, learning new things like a language or new IT technology is hard and takes time. There maybe times that you spend hours trying to get a simple playbook to work, at the time you feel super frustrated, but on reflection what you went through was a learning experience that helped you build even more knowledge of driving Ansible. This blog only really scratches the surface of Ansible and is more to pique your interest on the technology.