Ansible / Ansible Course / Automation / Cloud

Implementing Ansible Roles

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

Disclaimer:

The views expressed and the content shared in all published articles on this website are solely those of the respective authors, and they do not necessarily reflect the views of the author’s employer or the techbeatly platform. We strive to ensure the accuracy and validity of the content published on our website. However, we cannot guarantee the absolute correctness or completeness of the information provided. It is the responsibility of the readers and users of this website to verify the accuracy and appropriateness of any information or opinions expressed within the articles. If you come across any content that you believe to be incorrect or invalid, please contact us immediately so that we can address the issue promptly.

Tags: Ansible · ansible command · Ansible Doc · ansible playbook · ansible roles · ansible training · implementing roles

Comments