Ansible Network Automation: Architecture & Playbook example

Ansible Network Automation: Architecture & Playbook example

I liked how ansible is being designed in a very simple architecture to operate with any network element without adding complexity in addition to its ability to perform idempotent execution, meaning that running the same playbook multiple times results in a consistent state. This allows for safe and predictable automation.

Ansible is composed of several key components that work together to automate IT infrastructure tasks.

Here are the main components of Ansible:

Control Node

The control node is responsible for hosting the ansible platform from which the network admin runs Ansible CLI tools (ansible, ansible-playbook, ansible-vault) and others. Ansible can be installed on top of any any machine meeting the required system capabilities operating system (e.g. windows, Linux, ..).


Inventory

A list of managed nodes. Inventory support in providing details of managed nodes like hostname, IP address, network connection (e.g. ssh), managed node operating system (ios, iosxr, nexus, junos, esxi, ..).

Inventory enable grouping similar hosts having the same attributes with several benefits

  1. Easier management: Host groups allow you to organize your inventory based on logical groupings, such as by function, location, or environment. This makes it easier to manage your inventory, especially as it grows in size and complexity.
  2. Increased flexibility: Host groups allow you to define specific configurations or tasks for subsets of your inventory. For example, you can define tasks that only apply to switches or servers, rather than applying them to all hosts in your inventory.
  3. Simplified playbook development: Host groups allow you to develop playbooks that are focused on specific tasks or configurations for specific groups of hosts. This simplifies playbook development and reduces the risk of errors or conflicts when running playbooks on different types of hosts.
  4. Improved security: Host groups allow you to define specific security configurations or tasks for subsets of your inventory. For example, you can define different firewall rules or access control configurations for different groups of hosts, improving the security posture of your infrastructure.
  5. Faster execution: Host groups allow you to run playbooks concurrently on multiple hosts in a group, reducing the time it takes to execute tasks or configurations across your inventory.

Inventory in .ini format

Hosts are listed under [group-name], and the corresponding variables are listed under [group-name:vars]

# group managed iosxr nodes
[core-routers-cisco]
RT_CO_01 ansible_ssh_host=10.1.1.1
RT_CO_02 ansible_ssh_host=10.1.1.2

# list variables of managed group core-routers-cisco, mentioning its variables
[core-routers-cisco:vars]
ansible_user=admin
ansible_password=admin123
ansible_connection=network_cli
ansible_network_os=iosxr
ansible_port=22        

Inventory in .yml format

Hosts and corresponding variables are grouped in a simple format identifying the hostname, IP address, username, password, connection type, remote host OS and connection port number

---
# group of iosxr managed nodes, name core-routers-cisco, hosts and variables
core-routers-cisco
?hosts:
? RT_CO_01: 10.1.1.1
? RT_CO_02: 10.1.1.2
?vars:
? ansible_user: admin
? ansible_password: admin123
? ansible_connection: network_cli
? ansible_network_os: iosxr
? ansible_port: 22        

Playbooks

Playbooks is the basic unit of Ansible platform, They contain Plays. Playbooks are written in YAML and are easy to read, write, share and understand.

An Ansible playbook defines a set of tasks to be executed on one or more hosts. Here are the common components of an Ansible playbook:

  1. Name: The name of the playbook.
  2. Hosts: The hosts or groups of hosts targeted by the playbook. This can be specified using an inventory file or by explicitly specifying the host or groups in the playbook.
  3. Variables: The variables that are used in the playbook, which can be defined at the playbook level, or in an external file.
  4. Tasks: The main component of the playbook, which defines the set of tasks to be executed on the targeted hosts. Tasks can include running commands, copying files, installing packages, and performing other system administration tasks.
  5. Handlers: Handlers are tasks that are triggered by other tasks in the playbook. They are typically used to restart services or perform other actions that need to be executed only when certain conditions are met.
  6. Roles: Roles are a way to organize tasks and configurations into reusable components. They can be used to define common configurations for different hosts or groups of hosts, and can be shared across different playbooks.
  7. Conditional statements: Conditional statements allow you to control the flow of execution in the playbook based on certain conditions. This can include checking for the existence of files or directories, or checking the status of a service.
  8. Loops: Loops allow you to iterate over a set of values and perform the same set of tasks for each value. This can be useful for tasks such as creating multiple users or installing multiple packages.
  9. Tags: Tags allow you to specify which tasks are executed when running the playbook. This can be useful for running specific tasks or skipping certain tasks during playbook execution.

Below is a playbook is written in yaml format to extract the clock and uptime of remote iosxr routers listed in hosts file under group core-routers-cisco.

---
- name: backup config and look at device health indicators on iosxr devices
? hosts: core-routers-cisco
? gather_facts: no
? tasks:
? ?- name: run show commands on remote devices
? ? ?iosxr_command:
? ? ? commands:
? ? ? ?- show clock
? ? ? ?- show version | include uptime
? ? ?register: show_output
? ?- debug:
? ? ? msg: "{{ show_output.stdout }}"        

Command to run playbook cisco-rtr-check01.yml

[root@black_diamond ~]# ansible-playbook /etc/ansible/playbooks/cisco-rtr-check01.yml        

Playbook output

playbook runs two tasks

Task#1: run show commands on remote devices

This task will run and execute mentioned commands on the remote without logging the printing the output. this will be useless if we are gathering information from remote hots. printing the output will be achieved by saving the gathered information into variable show_output mentioned in line 11 of the playbook and printing this variable by the second task

Task#2: debug

In Ansible, the debug module is a powerful tool that allows you to print information and variables during playbook execution. It is used to display messages or the values of variables for debugging purposes. The debug module can be helpful in understanding the state of the system, troubleshooting issues, and verifying the values of variables at different stages of playbook execution.

[WARNING]: Invalid characters were found in group names but not replaced, use -vvvv to see details


PLAY [backup config and look at device health indicators on iosxr devices] ************************************************************


TASK [run show commands on remote devices] ********************************************************************************************
ok: [RT_CO_01]
ok: [RT_CO_02]


TASK [debug] **************************************************************************************************************************
ok: [RT_CO_01] => {
? ? "msg": [
? ? ? ? "22:59:23.845 EGY Fri Aug 4 2023",
? ? ? ? "R1RT_CO_01 uptime is 1 year, 22 weeks, 1 day, 18 hours, 7 minutes"
? ? ]
}

ok: [RT_CO_02] => {
? ? "msg": [
? ? ? ? "22:59:23.784 EGY Fri Aug 4 2023",
? ? ? ? "R1RT_CO_02 uptime is 1 year, 22 weeks, 17 hours, 27 minutes"
? ? ]
}



PLAY RECAP ****************************************************************************************************************************
RT_CO_01? ? ? ? ? ? ? ? ?: ok=2? ? changed=0? ? unreachable=0? ? failed=0? ? skipped=0? ? rescued=0? ? ignored=0
RT_CO_02? ? ? ? ? ? ? ? ?: ok=2? ? changed=0? ? unreachable=0? ? failed=0? ? skipped=0? ? rescued=0? ? ignored=0
        

Plugins

Plugins are pieces of code that augment Ansible’s functionality. Ansible uses a plugin to enable a rich, flexible and expandable feature set.


Collections

A format in which Ansible content is distributed that can contain playbooks, roles, modules, and plugins. You can install and use collections through?Ansible Galaxy.

Cisco IOSXR Collection is an example which includes a variety of Ansible content to help automate the management of Cisco IOSXR network appliances. it can be installed using ansible-galaxy command

ansible-galaxy collection install cisco.iosxr        

Sample of module included in Cisco IOSXR Collection

  • cisco.iosxr.iosxr_command: Module to run commands on remote devices
  • cisco.iosxr.iosxr_bgp_global: Resource module to configure BGP
  • cisco.iosxr.iosxr_facts: Module to collect facts from remote devices
  • cisco.iosxr.iosxr_lacp: Resource module to configure LACP
  • cisco.iosxr.iosxr_ospfv2: Resource module to configure OSPFv2
  • cisco.iosxr.iosxr_ospfv3: Resource module to configure OSPFv3


Please share with us in the comments the use cases you have used or developed with Ansible to automate your IT infrastructure and how beneficial they have been.



References


要查看或添加评论,请登录

Ibrahim ElSawy的更多文章

  • Ansible Network Automation: Modules

    Ansible Network Automation: Modules

    In today's hyper-connected world, where the demand for faster, more reliable, and secure networks continues to grow…

  • Ansible Network Automation: Introduction & Installation

    Ansible Network Automation: Introduction & Installation

    Ansible is a very popular open source automation platform. It was originally written by Michael DeHaan.

    1 条评论
  • Nexus 9K: Setting Boot Variables

    Nexus 9K: Setting Boot Variables

    N9K switch failed to boot from NXOS stored on bootflash NXS-SW-01# show boot Current Boot Variables: sup-1 NXOS…

    1 条评论
  • Virtual Port Channels

    Virtual Port Channels

    A virtual port channel (vPC) allows links that are physically connected to two different Cisco Nexus 7000 or 9000…

社区洞察

其他会员也浏览了