Ansible roles separate the logical function with a physical host to fit your network better. For example, you can construct roles such as spines, leafs, core, as well as Cisco, Juniper, and Arista. The same physical host can belong to multiple roles; for example, a device can belong to both Juniper and the core. This flexibility allows us to perform operations, such as upgrade all Juniper devices, without worrying about the device's location in the layer of the network.

Ansible roles can automatically load certain variables, tasks, and handlers based on a known file infrastructure. The key is that this is a known file structure that we automatically include. In fact, you can think of roles as pre-made include statements by Ansible.

The Ansible playbook role documentation (http://docs.ansible.com/ansible/playbooks_roles.html#roles) describes a list of role directories that we can configure. We do not need to use all of them. In our example, we will only modify the tasks and the vars folders. However, it is good to know all of the available options in the Ansible role directory structure.

The following is what we will use as an example for our roles:

├── chapter5_12.yml
├── chapter5_13.yml
├── hosts
└── roles
 ├── cisco_nexus
 │   ├── defaults
 │   ├── files
 │   ├── handlers
 │   ├── meta
 │   ├── tasks
 │   │   └── main.yml
 │   ├── templates
 │   └── vars
 │       └── main.yml
 └── spines
 ├── defaults
 ├── files
 ├── handlers
 ├── tasks
 │   └── main.yml
 ├── templates
 └── vars
     └── main.yml

You can see that, at the top level, we have the hosts file as well as the playbooks. We also have a folder named roles. Inside the folder, we have two roles defined: cisco_nexus and spines. Most of the subfolders under the roles were empty, with the exception of the tasks and vars folders. There is a file named main.yml inside each of them. This is the default behavior: the main.yml file is your entry point that is automatically included in the playbook when you specify the role in the playbook. If you need to break out additional files, you can use the include statement in the main.yml file.

Here is our scenario:

• We have two Cisco Nexus devices, nxos-r1 and nxos-r2. We will configure the logging server as well as the log link-status for all of them, utilizing the cisco_nexus role for them.
• In addition, nxos-r1 is also a spine device, where we will want to configure more verbose logging, perhaps because spines are at a more critical position within our network.

For our cisco_nexus role, we have the following variables in roles/cisco_nexus/vars/main.yml:

---
cli:
  host: "{{ ansible_host }}"
  username: cisco
  password: cisco
  transport: cli

We have the following configuration tasks in roles/cisco_nexus/tasks/main.yml:

---
- name: configure logging parameters
  nxos_config:
    lines:
      - logging server 191.168.1.100
      - logging event link-status default
    provider: "{{ cli }}"

Our playbook is extremely simple, as it just needs to specify the hosts that we would like to configure according to cisco_nexus role:

---
- name: playbook for cisco_nexus role
  hosts: "cisco_nexus"
  gather_facts: false
  connection: local

  roles:
    - cisco_nexus

When you run the playbook, the playbook will include the tasks and variables defined in the cisco_nexus role and configure the devices accordingly.

For our spine role, we will have an additional task of more verbose logging in roles/spines/tasks/mail.yml:

---
- name: change logging level
  nxos_config:
    lines:
      - logging level local7 7
    provider: "{{ cli }}"

In our playbook, we can specify that it contains both the role of cisco_nexus as well as spines:

---
- name: playbook for spine role
  hosts: "spines"
  gather_facts: false
  connection: local

  roles:
    - cisco_nexus
    - spines 

When we include both roles in this order, the cisco_nexus role tasks will be executed, followed by the spines role:

TASK [cisco_nexus : configure logging parameters] ******************************
changed: [nxos-r1]

TASK [spines : change logging level] *******************************************
ok: [nxos-r1]

Ansible roles are flexible and scalable – just like Python functions and classes. Once your code grows beyond a certain level, it is almost always a good idea to break it into smaller pieces for maintainability.

Ansible Galaxy (https://docs.ansible.com/ansible/latest/reference_appendices/galaxy.html) is a free community site for finding, sharing, and collaborating on roles. You can see an example of the Juniper networks supplied by the Ansible role on Ansible Galaxy:

In the next section, we will take a look at how to write our own custom Ansible module.