Network Automation with Red Hat Ansible Automation Platform

Creating roles in Ansible does not require any special development tools. Creating and using an Ansible Role is a three-step process:

Ansible looks for roles in a subdirectory called roles in the project directory containing your Ansible Playbook. Each role has its own directory with a standardized directory structure. This structure enables you to store roles with the playbook and other supporting files.

For example, the following directory structure contains the files within the layer3_interface role:

[user@host ~]$ tree roles/layer3_interface/
roles/layer3_interface/
├── README.md
├── default
│   └── main.yml
├── meta
│   └── main.yml
├── files
└── tasks
    ├── ios.yml
    ├── junos.yml
    └── main.yml

4 directories, 6 files

The README.md file provides a basic human-readable description of the role, documentation, examples of how to use it, and any non-Ansible role requirements.

The defaults subdirectory contains a main.yml file that defines the default values for the variables used in the role.

The meta subdirectory contains a main.yml file that specifies information about the author, license, compatibility, and dependencies for the role.

If a subdirectory exists but is empty, such as files in this example, then it is ignored. You can omit the subdirectory if the role does not use it.

The main.yml file in the tasks subdirectory contains the role's task definitions. In this example, the tasks subdirectory also contains specific tasks for Cisco IOS and Juniper Junos managed nodes in the ios.yml and junos.yml files.

Creating an Ansible Role Structure

You can create all the subdirectories and files needed for a new Ansible Role in VS Code, or by using standard Linux commands. Alternatively, you can also use the ansible-galaxy command.

Use the following procedure to create a role structure using the ansible-galaxy command:

1. Change to the roles directory in your project:

   [user@host project]$ cd roles
   [user@host roles]$

2. Run the ansible-galaxy init command, specifying the role name as an argument to create the role:

   [user@host roles]$ ansible-galaxy init vlans_configuration
   - Role vlans_configuration was created successfully

The following screen capture illustrates the directory structure created for the vlans_configuration role as displayed in VS Code:

Figure 6.1:

Skeleton for the vlans_configuration Role

After creating the directory structure, you need to write the content of the role. A good place to start is the ROLENAME/tasks/main.yml task file. This file contains the main list of tasks that the role runs.

As an example, suppose that you are creating an Ansible Role to configure Layer 3 (L3) interfaces for Cisco IOS and Juniper Junos managed nodes. You can create the following tasks/main.yml task file within the role:

---
- name: Load the right configuration task
  ansible.builtin.include_tasks: "{{ ansible_network_os }}.yml"

For Cisco IOS managed nodes, the ansible_network_os variable has the cisco.ios.ios value. For Juniper Junos managed nodes, the variable has the junipernetworks.junos.junos value. Depending on the value of that variable, the role configures the L3 interface for Cisco IOS managed nodes or for Juniper Junos managed nodes. Because the cisco.ios.ios.yml and junipernetworks.junos.junos.yml task files are defined within a role task, the files are retrieved from the role's tasks subdirectory.

You can create the tasks/cisco.ios.ios.yml task file with the following content:

---
- name: Configure L3 interface for Cisco IOS managed node
  cisco.ios.ios_l3_interfaces:
    config: "{{ l3_interface }}"

Similarly, you can create the tasks/junipernetworks.junos.junos.yml task file as follows:

---
- name: Configure L3 interface for Juniper Junos managed node
  junipernetworks.junos.junos_l3_interfaces:
    config: "{{ l3_interface }}"

---
- name: Configure L3 interface for Arista EOS managed node
  arista.eos.eos_l3_interfaces:
    config: "{{ l3_interface }}"

You can use the defaults/main.yml file to set the default value for the l3_interface variable. The value defined in the defaults subdirectory can be overwritten by defining the variable in the play that loads the role.

---
galaxy_info:
  author: Student
  description: Network managed nodes configuration
  company: Company, Ltd.
  license: GPL-2.0
  min_ansible_version: 2.1

dependencies:
  - role: node_backup
    path: backups
  - role: node_reload

When the role structure has been created and its content defined, you can use the role in a playbook.

You can use roles in playbooks in several ways. You can use the roles keyword in a play to run one or more roles before any tasks in the section defined by the tasks keyword. If you need to run some tasks before running the roles, then you can place those tasks in the section defined by the pre_tasks keyword.

For even more control of the order in which a role runs, use the ansible.builtin.include_role or the ansible.builtin.import_role module. By using these modules, you can run a role in a specific location in the play.

For example, the following playbook includes the role named layer3_interface, which configures the L3 interface on your managed nodes. Because the layer3_interface role is defined within a role task, the role is retrieved from the roles subdirectory in the project directory containing your playbook:

---
- name: Configure L3 interface on managed nodes
  hosts: all
  gather_facts: false
  tasks:
    - name: Load layer3_interface role
      ansible.builtin.include_role:
        name: layer3_interface

---
banner_text: Default message
banner_type: login

---
- name: Configure banners on managed nodes
  hosts: all
  gather_facts: false
  vars:
    - banner_text: This managed node is managed by Ansible
    - banner_type: motd
  roles:
    - role: banner

---
- name: Configure banners on managed nodes
  hosts: all
  gather_facts: false
  roles:
    - role: banner
      banner_text: This managed node is managed by Ansible
      banner_type: motd

Ansible Roles enable you to break down playbooks into multiple files, resulting in reusable code. To maximize the effectiveness of newly developed roles, consider implementing the following recommended practices into your role development:

A longer unofficial list of good practices to follow when you write a role is available at https://redhat-cop.github.io/automation-good-practices/#_roles_good_practices_for_ansible.