Ansible roles separate the logical function with 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 makes logical sense, as we can perform operation such as upgrade all Juniper devices across the network without their 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 premade and 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 you can configure. You do not need to use all of them; in fact, we will only modify the tasks and vars folder. However, it is good to know that they exist.

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 it, we have two roles defined: cisco_nexus and spines. Most of the subfolders under the roles were empty, with the exception of tasks and vars folder. 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 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, because they are of more critical positioning 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 be configured 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 spiens:

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

  roles:
    - cisco_nexus
    - spines 

Note that, when we do this, 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 them into smaller pieces for maintainability.