In the last couple of posts, we have heavily focused on Ansible and its usage vis-a-vis Network Management. Today, we will be utilizing what we have gone through so far to tackle a very common real world use case. It is recommended to have a sound understanding of Linux OS and its file structure, if one is really interested in getting a good grasp on Ansible.
The order of events that I personally like to go with, is given below. You can click on the link as well to jump to the relevant section.
- Objective
- Why the need ?
- Preparing the host file
- Writing the Playbook
- Executing the Playbook
- Taking a notch further
Use Case
Objective –
Automate daily/weekly/monthly backups of Network devices
Why the need ? –
In order to ensure a healthy IT operations environment with suitable disaster recovery mechanisms in place, it is essential to maintain a good & reliable backup of the configuration database. We always aim to avoid any system failures by keeping monitoring checks & balances in place but, no amount of monitoring or proactive maintenance can ensure 100% availability of production systems. Sooner or later, we will encounter a system failure and how quickly we manage to recover from such a failure would be a critical factor in defining the robustness of our processes.
In the context of Network Management, one of the most common factors to accelerate the recovery of production network is ensuring that we have a reliable and up to date backups of the running configuration of routers/switches/gateways. There are plenty of third party tools available in the market that can schedule backups of network devices at different frequencies/intervals. If you don’t already have a system in place to accomplish this objective and have the money then feel free to go for such tools. But if you want to resolve this problem in house without having your team members manually copying “show run” into Notepad all day long or help your customer without spending a dime while simultaneously learning something new then follow along.
Playbook –
This is a very simple Playbook that accomplishes our objective. If you are not clear about the syntax and what each line item means then please go through one of my earlier posts linked below.
- name: Config Backups
hosts: router
connection: network_cli
gather_facts: no
tasks:
- name: Config Backup
ios_config:
backup: yes
register: config_output
https://learnuccollab.com/2022/09/18/understanding-ansible-network-automation-made-easy/
Host File –
Before we run this playbook using command ansible-playbook /etc/ansible/backup.yml, let’s have a look at the contents of the host file as well that contains details of the network device against which we will be executing this playbook. You will see the following 3 new parameters which we hadn’t discussed in the last post.
- ansible_become : This specifies whether we want to have a provision for “privilege escalation” or not.
- ansible_become_method : This specifies which privilege escalation method should be used. For Cisco network devices, it’s the “Enable” mode.
- ansible_become_password : This specifies the password required to get into “enable” mode.
[ssingh@localhost ~]$ cat /etc/ansible/hosts
# This is the default ansible 'hosts' file.
#
# It should live in /etc/ansible/hosts
[router]
10.0.0.15 ansible_network_os=ios ansible_user=cisco ansible_password=cisco ansible_become=yes ansible_become_method=enable ansible_become_password=cisco
[ssingh@localhost ~]$
Executing the Playbook –
This execution of this playbook will result in the creation of a folder named “backup” followed by the dumping of the running config in it. The following is how the folder structure will look like. The line highlighted in yellow shows the newly created folder “backup”. The line highlighted in orange is the YAML Playbook whose contents were shown earlier.
-rwxrwxrwx. 1 root root 19985 Jan 15 2022 ansible.cfg
drwxrwxr-x. 2 ssingh ssingh 50 Sep 28 20:32 backup
-rw-rw-r--. 1 ssingh ssingh 280 Sep 28 20:31 backup.yml
-rwxrwxrwx. 1 root root 249 Sep 28 20:32 hosts
-rw-------. 1 ssingh ssingh 297 Sep 24 17:19 playbook.yml
The following is what you’ll see under the “backup” folder. The highlighted section shows the name of the file that contains the configuration of the network device. This name is comprised of 3 main elements (IP Address of the device, Date, Time). As you can see, the IP is 10.0.0.15 and the backup was taken at 12:17 PM on Oct 2nd.
The second section down the list shows a snippet of the contents of the backed up file.
[ssingh@localhost ~]$ ls -l /etc/ansible/backup
total 8
-rw-rw-r--. 1 ssingh ssingh 6142 Oct 2 12:17 10.0.0.15_config.2022-10-02@12:17:00
[ssingh@localhost ~]$
[ssingh@localhost ~]$ cat /etc/ansible/backup/10.0.0.15_config.2022-10-02@12:17:00
Building configuration...
Current configuration : 6082 bytes
!
! Last configuration change at 19:11:08 UTC Sun Oct 2 2022
!
version 17.3
service timestamps debug datetime msec
service timestamps log datetime msec
service call-home
platform qfp utilization monitor load 80
platform punt-keepalive disable-kernel-core
platform console virtual
!
hostname CSR1000
Now, this is good to demonstrate how such a playbook works. This accomplishes our objective of automating configuration backups of network devices. Some people might be content with this and stop here. However, we can take it a notch further.
Cherry on Top –
In a production environment, we would probably want to have daily or weekly backups of hundreds of network switches/routers/gateways. This means that someone will have to manually run this playbook on a daily or whatever frequency basis. Some people might find it fine too. They can just assign someone in the team to run the playbook everyday or every week etc. But isn’t that a waste of resource & time ? Plus, we are again bringing a variable in this setup by relying on a person to perform this job. What if he/she is not available or just forgot to run the job or the team simply started taking it casually as the time went on etc. If we want to automate this process end to end then we need to get rid of this variable. And it’s pretty easy to do that. We can just schedule the execution of the playbook as a Linux cron job.
The following is how the contents of my cron file look like. I’ve edited the default root level Crontab file using sudo for demonstration purposes only. In a production environment, it is always recommended to use user profile specific cron files instead of the root one. The highlighted statement is the meat of this file. We are basically scheduling the ansible-playbook /etc/ansible/backup.yml command to execute at 12:43 PM on the 2nd of every month.
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
43 12 02 * * ssingh ansible-playbook /etc/ansible/backup.ymlNow, if we take a look at the contents of the backup folder again, then we see the following. This is the backup file that got generated as a part of our automated cron job. If you follow the naming convention as explained earlier then it’s clear that the file was generated at 12:43:05 PM on Oct 2nd.
[ssingh@localhost ~]$ ls -l /etc/ansible/backup
total 16
-rw-rw-r--. 1 ssingh ssingh 6142 Oct 2 12:17 10.0.0.15_config.2022-10-02@12:17:00
-rw-r--r--. 1 ssingh ssingh 6142 Oct 2 12:43 10.0.0.15_config.2022-10-02@12:43:05
I hope this post was useful in once again demonstrating how effective Ansible can be with respect to Network Management. We will be exploring Ansible in much more detail in the future and see how we can expand its usage & make it more dynamic through Jinja2 templates and other advances features. We will also go through some more real world scenarios in the coming posts. So, stay tuned.
Please feel free to drop your feedback/suggestions, if any. Until then, Happy Learnings!!
Learn UC Collaboration 