In a production environment, we will have hundreds and thousands of different types machines to handle. Hence the type of operations and implementation methods will be different from one to another. You can add different tasks or handlers for each type of operation or host, but managing such a playbook is not an easy job. By using Ansible Roles, you can organize your playbook into smaller and separate playbooks.
See all parts of Automation with Ansible Guides here
You can include all the required variables, tasks, template file, other files etc in the role directory itself. Hence your ansible project file and directory will be arranged in a more organized manner. Roles can also written in a manner where you forecast the re-use of roles.
- By using roles, you can easily share your play with other teams by sharing the entire role directory. Eg: you can write a role for install_dbserver or setup_webserver, later can share to public/other teams.
- Larger projects can create in a modular way and easy to manage.
- Even different user can create different roles in parallel and share to same project. eg: user1 write a role for install_dbserver and userb focus on setup_webserver role.
Roles Directory Structure
As I mentioned above, content of role are arranged in an orgnaized way as below. The top level directory defines the name of the role itself. You can see, I have two roles named myapache and dbsetup roles in my roles directory. Some of the directories contains main.yml which is the main file containing tasks, variables or handlers.
.
├── ansible.cfg
├── apache.yml
├── inventory
└── roles
├── myapache
│ ├── defaults
│ │ └── main.yml
│ ├── handlers
│ │ └── main.yml
│ ├── meta
│ │ └── main.yml
│ ├── README.md
│ ├── tasks
│ │ └── main.yml
│ ├── templates
│ │ ├── apache_httpdconf.j2
│ │ └── apache_indexhtml.j2
│ ├── tests
│ │ ├── inventory
│ │ └── test.yml
│ └── vars
│ └── main.yml
└── dbsetup
├── defaults
│ └── main.yml
├── files
│ └── profile.png
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── README.md
├── tasks
│ └── main.yml
├── templates
│ └── mkcd.sh.j2
├── tests
│ ├── inventory
│ └── test.yml
└── vars
└── main.yml
Here see the directory details.
- defaults – main.yml contains variables for the role which can be overwritten when role is used
- tasks – main.yml contains the main list of tasks to be executed when using the role.
- vars – main.yml contains variables for the role
- files – static files which can be referenced from this role.
- templates – jinja2 templates which can be used via this role.
- handlers – main.yml contains handler defenitions
- meta – main.yml defines some meta data for this role like author, license, platform, dependencies etc.
- tests – contains an inventory and test.yml that can be used for testing this role.
You can define the default variables under defaults/main.yml and additional role variables inside vars/main.yml.
How to use roles in your playbook
You can call your role in your main playbooks as below.
---
- name: Setup apache on serverb
hosts: serverb.techbeatly.com
roles:
- role: myapache
apache_enable: true
You can in above sample, I have mentioned a variable for the role as apache_enable: true.
You can also include multiple roles and variables as lised below.
---
- name : Setup dbserver and webserver
hosts: all
roles:
- role: dbsetup
- role: myapache
db_server: mariadb
db_port: 4323
apache_port: 443
Please note, you can have multiple yml files inside the directories like tasks/main.yml, tasks/webinstall.yml, tasks/enablefw.yml etc.
Role Dependencies
Role dependency is a feature which will allow a role to include other roles as dependencies inside a playbook. Dependencies are defined inside the meta/main.yml file inside role directory, . The file should contain a list of roles and parameters to insert before the specified role, as shown below
---
- dependencies:
- { role: myapache, port: 8080 }
- { role: allowfirewall, firewall_port: 8080, enable_fw: true }
Role dependencies are always executed before the role that include them. (That’s what we call dependency right). If the same dependency was mentioned by another role, the dependency will not execute again. You can override this feature by using allow_duplicates: true inside the meta/main.yml file
Control Roles and Tasks Execution
When you include a role in your playbook, tasks inside the role will be executed before the tasks in the playbook. In some cases, you may need to run some other tasks before the role tasks. For that purpose, you can use pre_tasks and post_tasks options.
---
- name: Setup apache on serverb
hosts: serverb.techbeatly.com
pre_tasks:
- debug:
msg: "This will run before the roles
roles:
- myapache
- dbsetup
tasks:
- debug:
msg: "tasks in role completed; this is after roles"
post_tasks:
- debug:
msg: "All done"
import_role or include_role
From Ansible 2.4 onwards, you can use roles inline with any other tasks in play- like calling a function – by using import_role or include_role feature.
---
- hosts: all
tasks:
- debug:
msg: "Just a task before I include role"
- import_role:
name: myapache
- include_role:
name: dbsetup
- debug:
msg: "Another tasks after I include role"
Refer Ansible Doc for more details.
Let’s cover Ansible Galaxy in next session.
See all parts of Automation with Ansible Guides here