Ansible, originally developed by Michael DeHaan and later acquired by Red Hat, has become increasingly popular due to its user-friendly interface, adaptability, and capacity to streamline a wide range of automation tasks.
One common challenge encountered when mastering Ansible playbooks is the repetition of code. Many playbooks often share similar tasks but serve different purposes. To tackle this issue effectively, Ansible Roles come into play.
With Ansible Roles, you can compartmentalize your playbooks into distinct directories and files, making it ideal for seamless scalability – whether it involves simple tasks or complex deployments encompassing numerous operations. This approach not only eliminates code redundancy but also provides a well-organized structure, making it effortless to locate and manage variables, files, templates, passwords, and more.
Role Structure
First, we need to know the role structure. It is a set of folders and files with specific names to sort our information.
Each role must have a unique name. For example, we can use the role webserver. When we create this role, we will have a structure like this:
└── webserver
├── defaults – Default variables that can be overridden.
│ └── main.yml
├── files – Holds files to be uploaded to hosts
├── handlers – Handlers
│ └── main.yml
├── meta – Dependency information about a role
│ └── main.yml
├── README.md – File to write documentation about the role
├── tasks – Tareas
│ └── main.yml
├── templates – Nuestros templates jinja2
├── tests – Files to test the role.
│ ├── inventory – Test inventory.
│ └── test.yml – Entry point to tests.
└── vars – Variables that shouldn’t be overridden.
└── main.yml
Each directory is not mandatory. If your role uses a handle, it is optional for this directory.
Where does Ansible look up the roles?
Ansible will search into the roles directory in the same place where the playbook is. Also in the /etc/ansible/roles directory. In the file ansible.cfg, you can customize the roles directory by modifying the roles_path variable.
sing Roles in our playbooks
A playbook that uses Roles looks like this:
– name: deploy Django app
hosts: web
vars_files:
– secrets.yml
Roles:
– role: database
database_name: “{{ django_proj_name }}”
database_user: “{{ django_proj_name }}”
– role: mezzanine
live_hostname: 192.168.200.10.local
domains:
– 192.168.200.10.local
– www.192.168.200.10.local
Pre-Tasks and Post-Tasks
Sometimes, we want to execute tasks before or after calling the roles. An example could be to update the apt-cache before deploying the application or send a notification message to a slack channel after completing all deployment tasks.
To resolve those necessities, Ansible defines a list of tasks to execute before roles named pre_tasks and a list of tasks to complete before roles named post_tasks. Those tasks look like this:
– name: deploy Django app
hosts: web
vars_files:
– secrets.yml
pre_tasks:
– name: update the apt cache
apt: update_cache=yes
roles:
– role: mezzanine
database_host: “{{ hostvars.db.ansible_eth1.ipv4.address }}”
live_hostname: 192.168.200.10.local
domains:
– 192.168.200.10.local
– www.192.168.200.10.local
post_tasks:
– name: notify Slack that the servers have been updated
local_action: >
slack
domain=iw.slack.com
token={{ slack_token }}
msg=”web server {{ inventory_hostname }} configured”
Conclusion
In conclusion, this overview offers insight into Ansible Roles, helping you grasp their key features and begin harnessing their power. For comprehensive documentation on roles and in-depth guidance, you can explore the official Ansible website at: https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html