Bookmark this page

P 1 2 3 4 5 6 7 8

Chapter 2. Implementing an Ansible Playbook

Section Building an Ansible Inventory

SectionObjectives
SectionThe Purpose of an Ansible Inventory
SectionBuilding a Static Ansible Inventory
SectionUsing Automation Content Navigator to Browse the Ansible Inventory

Guided Exercise: Building an Ansible Inventory

Configuring Automation Content Navigator

Objectives
Format of the Settings File
Locating the Settings File
Generating a Settings File

Guided Exercise: Configuring Automation Content Navigator

Writing and Running Playbooks

Objectives
Formatting an Ansible Playbook
Network Automation Modules
Using Handlers to Make Persistent Changes to Managed Network Nodes
Finding Modules for Tasks
Running Playbooks

Guided Exercise: Configuring Device Login Banners

Implementing Multiple Plays

Objectives
Writing Multiple Plays
Privilege Escalation
Selecting Modules
YAML Syntax

Guided Exercise: Creating a Cross-vendor Configuration Backup

Lab: Implementing an Ansible Playbook

Summary

Abstract

Goal	Create an inventory of managed nodes, write a simple Ansible Playbook, and run the playbook to automate tasks on those nodes.
Objectives	Describe Ansible inventory concepts and manage a static inventory file. Describe where automation content navigator configuration files might be located and edit them to apply changes to default settings. Write a basic Ansible Playbook and run it using the automation content navigator. Write a playbook that uses multiple plays and per-play privilege escalation, and effectively use automation content navigator to find new modules in available Ansible Content Collections and use them to implement tasks for a play.
Sections	Building an Ansible Inventory (and Guided Exercise) Configuring Automation Content Navigator (and Guided Exercise) Writing and Running Playbooks (and Guided Exercise) Implementing Multiple Plays (and Guided Exercise)
Lab	Implementing an Ansible Playbook

Building an Ansible Inventory

Objectives

Describe Ansible inventory concepts and manage a static inventory file.

The Purpose of an Ansible Inventory

An inventory file defines nodes in your network topology that Ansible manages. You can organize the managed nodes in groups. Groups can contain child groups, and the managed nodes can be members of many groups. You can also set variables in the inventory that apply to one managed node, or a group of them.

You use the inventory to define the set of nodes against which you run one or more tasks in a playbook.

The inventory can be static or dynamic. A static inventory is a single text file with a list of the managed nodes. The managed nodes and groups in a static inventory are fixed as long as you do not manually change them. A dynamic inventory generates a list of nodes and groups in real time. To generate a dynamic inventory, you can use a script that queries an external source, such as a configuration management database (CMDB). You can create the script, take it from the open source community, and so on.

The use of dynamic inventories is beyond the scope of this course. You can find more information about dynamic inventories at https://docs.ansible.com/ansible/latest/inventory_guide/intro_dynamic_inventory.html

Building a Static Ansible Inventory

You can build a static Ansible inventory using different formats. In this course, you focus on learning the INI-style format. You can use Visual Studio Code or any other editor to create the file.

The following example is a simple static inventory file written in the INI-style format. This Ansible inventory contains a simple list of managed nodes. You can use hostnames or IP addresses for the managed nodes.

iosxe1.lab.example.com
iosxe2.lab.example.com
junos.lab.example.com
arista.lab.example.com

You can improve the Ansible inventory by defining groups of managed nodes and including variables that apply to them.

Defining Groups of Managed Nodes

Use brackets to define groups of managed nodes, and add the list of nodes to the group. You can use blank lines between groups for better readability.

The following example contains three groups of managed nodes in the Ansible inventory. The cisco group contains the iosxe1.lab.example.com and iosxe2.lab.example.com managed nodes. The juniper and arista groups contain only one managed node each.

[cisco]
iosxe1.lab.example.com
iosxe2.lab.example.com

[juniper]
junos.lab.example.com

[arista]
arista.lab.example.com

A managed node can belong to more than one group in the Ansible inventory. In the previous example, suppose that you have the managed nodes distributed in the dc1 and dc2 data centers. If you plan to run some tasks on the nodes of one of the data centers, then consider defining groups with that information.

In the following inventory, all the managed nodes belong to more than one group. For example, the iosxe1.lab.example.com node belongs to the cisco group and to the dc1 group. You can use as many groups as you need to organize your inventory.

[cisco]
iosxe1.lab.example.com
iosxe2.lab.example.com

[juniper]
junos.lab.example.com

[arista]
arista.lab.example.com

[dc1]
iosxe1.lab.example.com
junos.lab.example.com

[dc2]
iosxe2.lab.example.com
arista.lab.example.com

Special Groups of Managed Nodes

All Ansible inventories contain two special groups: the all and the ungrouped groups.

all: This group contains all the managed nodes in the Ansible inventory.
ungrouped: This group contains all managed nodes that do not belong to any group. Ungrouped nodes appear at the top of an inventory file before the first group is defined.

You are not required to define either the all or the ungrouped groups in the Ansible inventory because they always exist.

Creating Nested Groups

The inventory can include groups of groups. You can create such groups by adding the :children suffix to the parent group. In the following example, the routers group includes the cisco, juniper, and arista groups.

[cisco]
iosxe1.lab.example.com
iosxe2.lab.example.com

[juniper]
junos.lab.example.com

[arista]
arista.lab.example.com

[routers:children]
cisco
juniper
arista

A group can have both individually managed nodes and groups of managed nodes as members. The individually managed nodes should be listed in the group, and the members that are groups should be placed as children.

In the following example, the parent cisco group consists of three managed nodes: the two members of the ios group, and the nxos.lab.example.com managed node.

[ios]
iosxe1.lab.example.com
iosxe2.lab.example.com

[cisco]
nxos.lab.example.com

[cisco:children]
ios

Using Ranges to Simplify the Ansible Inventory

Sometimes the managed nodes in your Ansible inventory might have a pattern in their names. You can use a special syntax to add a range of managed hosts to the inventory. Ranges can be numeric or alphabetical.

In the following example, instead of writing twenty lines under the group name, you can define a range of managed nodes in the cisco group using a simplified syntax:

[cisco]
iosxe[01:20].lab.example.com

The meaning of the [START:END] syntax is as follows:

START defines the start of the range.
END defines the end of the range.

The ranges include all values from START to END. Consider the following examples:

192.168.[4:7].[0:255] matches all IPv4 addresses in the 192.168.4.0/22 network (192.168.4.0 through 192.168.7.255).
core-rtr-[01:20].example.com matches all hosts named core-rtr-01.example.com through core-rtr-20.example.com.
[a:c].dns.example.com matches hosts named a.dns.example.com, b.dns.example.com, and c.dns.example.com.
2001:db8::[a:f] matches all IPv6 addresses from 2001:db8::a through 2001:db8::f.

If leading zeros are included in numeric ranges, they are used in the pattern. The second example above does not match core-rtr-7.example.com but does match core-rtr-07.example.com.

You can also specify a range where there are increments between the sequence in the name of the managed nodes.

Suppose that you have distributed your managed nodes from the previous example in the dc1 and dc2 data centers. The managed nodes with an odd number in their names (iosxe01.lab.example.com, iosxe03.lab.example.com, and so on) are in the dc1 data center. The managed nodes with an even number in their names (iosxe02.lab.example.com, iosxe04.lab.example.com, and so on) are in the dc2 data center. The simplified Ansible inventory looks like the following:

[cisco]
iosxe[01:20].lab.example.com

[dc1]
iosxe[01:20:2].lab.example.com

[dc2]
iosxe[02:20:2].lab.example.com

The meaning of the [START:END:STRIDE] syntax is as follows:

START defines the start of the range.
END defines the end of the range.
STRIDE defines the increment between the sequence of elements in the range.

Including Variables in the Ansible Inventory

You can define variables for managed nodes in the Ansible inventory file. These variables might be used by your Ansible Playbook, or they might be used to provide additional information about how Ansible connects to those managed nodes. For example, you might use the ansible_host variable to point to an IP address if the managed node does not have a DNS entry.

In the following example, a play that uses the nxos.lab.example.com managed node connects to it by using the 10.80.1.251 IP address.

nxos.lab.example.com ansible_host=10.80.1.251

You can define variables for single managed nodes (host variables), and variables that affect an entire group in your Ansible inventory (group variables). You can use the host variables and the group variables later in your playbooks.

In the following example, you define the private_ip host variable with the 172.25.250.23 value in the Ansible inventory. You can then use the private_ip value as the IP address of the nxos.lab.example.com managed node in a private network that is reachable by the control node.

nxos.lab.example.com private_ip=172.25.250.23

To define group variables, add the :vars suffix to the group in the Ansible inventory. For example, Ansible treats the managed nodes in the Ansible inventory as network devices if you define the ansible_connection variable with the netcommon.network_cli value. You might define this variable for specific groups of network devices, or you might create a group that contains all your network devices, such as the network_devices group.

[network_devices:vars]
ansible_connection=ansible.netcommon.network_cli

The ansible_network_os variable is commonly used by network devices to indicate the network platform to which the managed node corresponds. In the following example, the ansible_network_os variable is set to cisco.ios.ios for the managed nodes in the cisco group, and is set to arista.eos.eos for the managed nodes in the arista group.

[cisco]
iosxe1.lab.example.com
iosxe2.lab.example.com

[arista]
arista.lab.example.com

[cisco:vars]
ansible_network_os=cisco.ios.ios

[arista:vars]
ansible_network_os=arista.eos.eos

Using Automation Content Navigator to Browse the Ansible Inventory

To display the contents of your Ansible inventory, you can use the ansible-navigator command with the inventory subcommand.

[user@host ~]$ ansible-navigator inventory

To specify an Ansible inventory path that is not the default, use the --inventory (or the -i) option.

[user@host ~]$ ansible-navigator inventory --inventory ~/my_inventory

The following output shows the two possible options to explore the Ansible inventory.

Figure 2.1: Browsing the Ansible inventory with automation content navigator

Browsing Groups

Type 0 in the main Ansible inventory page to explore the groups and group members of the Ansible inventory.

Figure 2.2: Listing the Ansible inventory groups

Enter the number of the group that you want to explore. If the number of the group is greater than nine, type a colon before the group number, and then press Enter.

For example, to list the managed nodes in the dc2 group in the previous output, type 2 or :2 followed by Enter.

Figure 2.3:

Managed nodes in the dc2 group.

You can continue pressing the number of the item you want to explore, or you can press Esc to go back one level. Press Esc as many times as you need to go back some levels, to return to the main page, or to exit the ansible-navigator command. You can also type :q to exit.

Browsing Managed Nodes

Type 1 in the main Ansible inventory page to explore the list of managed nodes in your Ansible inventory.

Figure 2.4: Listing the Ansible inventory managed nodes

To obtain more information about a managed node, type the number of the node, or type a colon, the node number, and Enter.

The following output shows the information for the iosxe1.lab.example.com managed node from the previous example.

Figure 2.5: Specific information about a managed node

Exploring the Ansible Inventory in `stdout` Mode

By default, the ansible-navigator command uses the text-based user interface. To disable this interactive mode, run ansible-navigator inventory using the --mode stdout (or -m stdout) option.

When browsing an Ansible inventory using the -m stdout option, you have to specify one of the following actions:

To create an inventory graph, use the --graph action.
To specify a managed node, use the --host HOST action.
To output all host information in JSON format, use the --list action.

The following example shows the output using the --graph action:

[user@host ~]$ ansible-navigator inventory -m stdout --graph
@all:
  |--@ungrouped:
  |--@dc1:
  |  |--iosxe1.lab.example.com
  |  |--junos.lab.example.com
  |--@dc2:
  |  |--iosxe2.lab.example.com
  |  |--arista.lab.example.com
  |--@routers:
  |  |--@cisco:
  |  |  |--iosxe1.lab.example.com
  |  |  |--iosxe2.lab.example.com
  |  |--@juniper:
  |  |  |--junos.lab.example.com
  |  |--@arista:
  |  |  |--arista.lab.example.com

The --graph action can also be used to create the inventory graph of only one group of the inventory:

[user@host ~]$ ansible-navigator inventory -m stdout --graph routers
@routers:
  |--@cisco:
  |  |--iosxe1.lab.example.com
  |  |--iosxe2.lab.example.com
  |--@juniper:
  |  |--junos.lab.example.com
  |--@arista:
  |  |--arista.lab.example.com

References

How to Build Your Inventory - Ansible Documentation

Groups and Variables in an Inventory File - Ansible Documentation

Discuss Network Automation with Red Hat Ansible Automation Platform

Go to community

Welcome to the Red Hat Ansible for Network Automation (DO457) group!

Syed

26 wrz 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat Ansible for Network Automation! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to DO457.Read more about Red Hat Ansible for Network Automation here.

3120

Revision: do457-2.3-7cfa22a

Network Automation with Red Hat Ansible Automation Platform