Depending on your personal background there are many different ways to approach networks or (more general) infrastructure devices in a programmatic way. If you are blessed with sufficient coding skills, please go straight to Python and frameworks like Nornir to get things started. This post though is for long time network engineers with little or no software experience.
Based on several kick-off sessions with ‘automation newbies’ over the last years, I would recommend to start with:
- Linux
- YAML
- Ansible
I won’t describe every step in full detail, but guide you through the initial phase and point out some useful resources as well.
Linux fundamentals
If you are not using a Linux desktop or have (root) access to another Linux host, it makes total sense to install a VM on your local machine. A Windows user can utilize Hyper-V or VirtualBox with a Linux distribution of choice, like Debian, Ubuntu, CentOS.
Things you need to know about Linux with regards to the required automation tooling:
- How to ssh into your Linux host (Putty for example)
- How to navigate (+ understand) the structure of the directory (cd, pwd, / , ~, …)
- How to handle basic file operations (cp, mv, mkdir, rm, touch, …)
- How to edit files (vim, nano, …)
- How to transfer files to/from your Linux host (WinSCP for example)
- How to install software using the packet manager
As most network engineers have a strong Linux / Unix history or have the pleasure to work with Linux based network operating systems already on a daily basis, I stop it right here.
YAML
YAML (‘Yet Another Markup Language‘ or ‘YAML Ain’t a markup language’ if you like recursions) is the go-to if you want to provide structured data in a machine readable format which is highly human readable as well. I know that seasoned infrastructure folks love to hate YAML, but from my experience it is a perfect fit for absolute beginners in the light of possible alternatives like JSON or XML. Since even Kubernetes uses YAML for almost every definition file, there is definitely no way around it anymore.
So, YAML is used to write Ansible playbooks and has one ‘weakness’, which imposes the greatest challenge for most people: Indentation!
---
- hosts: webservers
vars:
http_port: 80
max_clients: 200
is not the same as
---
- hosts: webservers
vars:
http_port: 80
max_clients: 200
So, whenever you encounter an Ansible execution error, please look at the proper indentation of your playbooks at first! Text editors like Visual Studio Code or Atom do help with getting it right, but as most people start with a simple vim or nano local to the Ansible host, this is the most common error at the beginning.
NRELabs has a great, simple to consume Introduction to YAML lesson, which you might try out at first. The Ansible relevant YAML Syntax can be found here.
Ansible
Now that Ansible and terms like playbooks have been mentioned before, it is time to introduce: Ansible is an open source, Python-based, agentless automation platform for the entire IT-Stack. Yes, the entire IT-Stack – From basic infrastructure like Networking or Firewalling over the Compute/Hypervisorlayer up to the Application itself. The whole IT-Department of an Enterprise organisation is now able to speak a common automation language.
Agentless is a key factor in the networking space, because you are simply not able or allowed to install a software agent on every networking device. Ansible is able to ssh into devices and do the automation thing by simply interacting with the device CLI (but it is also able to leverage interfaces like REST-API or Netconf if your platform supports it).
The two main building blocks are Inventory files and playbook files.
- Inventory
A list of managed devices (=hosts), with additional information like FQDN/IP or device specific variables. Grouping and hierarchical structure are possible as well. - Playbook
A collection of ‘plays’ including one or more tasks to be executed on selected hosts.
That’s it!
Additionally, there are all sorts of tricks available like looping and conditionals to make Ansible look more like a higher programming language. But the roots, and the beauty of simplicity by the way, is a plain serial processing of single tasks.
Tasks by itself leverage predefined Ansible network modules, which are available for almost every major networking platform out there. Most of them are idempotent, meaning that changes are only applied when it is required and you can run playbooks multiple times with the same result.
The following task example configures the hostname of a Cisco IOS device:
- name: configure hostname according to ansible inventory
ios_config:
lines: hostname {{ inventory_hostname }}
See what I did there? A sneak preview of how variables look like in the Ansible context: {{ inventory_hostname }} equals RT_AA for the first host in the inventory above.
To bind inventory and playbook together simply execute the ansible-playbook program, referencing the desired playbook:
[nwmichl@localhost /etc/ansible/]# ansible-playbook -k test.yml
Using the -k option, Ansible prompts for your password and uses the local user executing the playbook at the Ansible host to log into the network devices.
This preserves your audit trail during the first attempts with production equipment, avoiding a generic ‘ansible-user’ and also solves the problem of securely handling credentials – for now.
Prerequisites
Installation of Ansible is pretty straight forward, a simple
$ sudo yum install epel-release
$ sudo yum install ansible
gets the job done on CentOS/RHEL, including all the necessary dependencies.
If you have no physical lab equipment to play with, just spin up some virtual instances from your favorite vendor:
- VyOS Router, VyOS, 1 vCPU + 0,5GB RAM
- Cisco CSR1000v, IOS-XE, 1 vCPU + 2,5GB RAM
- Cisco Nexus9000v, NX-OS, 1 vCPU + 4GB RAM
- Arista EOSv-Lab, EOS, 2 vCPU + 4GB RAM
- Juniper vSRX Trial, Junos, 2 vCPU + 4GB RAM
- Cumulus VX, Cumulus Linux, 2vCPU + 1GB RAM
- …
I know, there are regwalls and some (bandwidth/feature/trial) limitations, but hey, it’s free and gets us started.
The next steps: Get your lab set up (control node with a working Ansible installation, 2-3 Network devices, network connectivity via ssh) and start building your first simple playbooks. Some ideas coming right up via the next post.
Headerimage by freepngimg.com
NWMichl Blog 