Ansible Roles Tutorial

We have learned how to execute the various Ansible statements in the Ansible terminal through this tutorial. We also covered how to create a playbook in Ansible and we will list and execute the various tasks in the playbook. We are going to learn about the roles in Ansible today. The role is a method for rearranging any item in Ansible.

The structure of roles in Ansible allows us to import specific parameters automatically, actions, documents, scripts, and controllers that are based according to a predefined document format in Ansible. The main method for partitioning a playbook into many documents is the role. It facilitates the creation of complicated playbooks and it also facilitates how we will reuse them in Ansible. By dividing the playbook, you may separate it into multiple reusable parts. So, every role is restricted to a specific feature or intended results. Each of the procedures, required to deliver the conclusion that was being kept within that particular role itself, are defined as dependents in other roles.

Structure of Roles in Ansible

Now, let us understand the basic structure of Ansible roles. For utilizing roles in ansible, we will create a new directory with the exact identity of every role. In the role hierarchy, the documents are arranged in a subdirectory manner. To create the directory, we will employ the following ansible-galaxy role command:

[root@master ansible]# ansible-galaxy init win_package_install_role

After running the command above, we will get the following desired outcome:

- Role win_package_install_role was created successfully

Since ansible-galaxy itself is included in the ansible tool, we do not need to install any further components for it. If you want to check the hierarchical structure of the role and several directories with modifiable layout, documents will be displayed after running the command below:

[root@master ansible]# tree win_package_install_role

As shown, we now have a total of 8 available directories in the role named “win_package_install_role” and 8 changeable documents.

Sometimes, we need to update documents like and meta/main.yml to properly describe your role even though it is not necessary for the role to function. It is essential to include any requirements in meta/main.yml if the role needs to access additional roles to run. This will enable Ansible to accomplish this as necessary. To Enter into the new directory, which we have recently created, we will write the statement below in the terminal.

[root@master ansible]# cd win_package_install_role

Then, it will show the new directory added to the main path shown below:

[root@master ansible] ~/win_package_install_role#

There are no prerequisites necessary for your win_package_install_role role. A functioning meta-file format is shown here as an example. If you want to change it to reflect your name, the name of your business, and, if appropriate, also change the license by writing the following command:

[root@master ansible] ~/win_package_install_role# nano meta/main.yml

Specifying the Tasks of Role in Ansible

Most often, the role would carry out one or even more activities to set up the remote device under the role’s criteria. Installing and setting up win_package_install_role is what we should do in this situation.

win_package_install_role /tasks/main.yml:
When we run a role, it searches by default the “tasks” subfolder for a document called main.yml and then we will list all the tasks in it. For more complex roles, you can divide the tasks into multiple documents and call them from main.yml using the include tasks or import tasks modules. Below is the command we will use to get into the task’s directory.

# tasks file for win_package_install_role
- name: Fetching {{product_name}} installation status
 win_shell:'Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object -Property DisplayName -like "*{{product_name}}*" |Format-Table IdentifyingNumber, Name, DisplayName, LocalPackage -AutoSize'
  register: installation_status

- debug:
      - "Product already installed"
      - "{{installation_status.stdout_lines}}"
  when: installation_status.stdout_lines is defined and installation_status.stdout_lines | length > 0

- meta: end_play
  when: installation_status.stdout_lines is defined and installation_status.stdout_lines | length > 0

- name: Create target directory if not exists
    path: "{{target_machine_path}}"
    state: directory

- name: Download the installer
    url: "{{url_to_download_setup}}"
    dest: "{{target_machine_path}}"
  register: download
  when: url_to_download_setup is defined and url_to_download_setup != ""

- set_fact:
    package_name_zip: "{{download.dest}}"
  when: download.failed == false

- name: Decompress the package
    src: "{{package_name_zip}}"
    dest: "{{target_machine_path}}"
    delete_archive: yes
  register: decompress_status
  when: (package_name_zip is defined) and (".zip" in package_name_zip or ".gz" in package_name_zip or ".gz" in package_name_zip)

- name: Find setup file location
    paths: "{{target_machine_path}}"
    patterns: [ "{{setup_name}}" ]
    recurse: true
  register: result

- name: Setting setup path for provided windows package
    setup_path: "{{result.files[0].path}}"
  when: result.failed == false and result.matched > 0

- name: Installing "{{setup_name}}"
    path: "{{setup_path}}"
    product_id: auto
    state: present
    arguments: /q
  register: status

- debug:
    msg: "{{setup_name}} installed successfully"
  when: status.rc == 0

- set_fact:
    reboot_required: true
  when: status.reboot_required is defined and status.reboot_required  

    - Reboot the windows server

In this document, we have done tasks like we have retrieved the name of the product. We have made a target directory if the directory is not available. We have to download the URL, uncompress the package, found the location of the setup, and we have also set the location for window package, etc.

win_package_install_role /default/main.yml:
The default parameters are defined inside the default directory. The default parameters are those with the utmost significance, making them simple to modify. The parameter defined in defaults/main.yml would be utilized if it is not defined anywhere.

# defaults file for win_package_install_role
target_machine_path: C:\ProgramFiles

win_package_install_role /var/main.yml:
To specify the parameters required for the role, we build a var document in this step. To avoid any title disputes with parameters from outside the role, it is a smart option that we will prefix the identifiers of the role parameters.

# vars file for win_package_install_role
product_name: apache
setup_name: httpd-2.2.25-win32-x86-no_ssl.msi
target_machine_path: C:\Installers

win_package_install_role /handlers/main.yml:
The handlers of the Ansible will be stored inside the handler’s directory. The tasks in the document are known as handlers that can be marked throughout a play for execution after it is over. We could employ handlers as we deem necessary.

# handlers file for win_package_install_role
- name: Reboot windows server
  when: reboot_required

win_package_install_role /meta/main.yml:
Once we decide to broadcast the role on, we will utilize the meta directory to contain author metadata. Ansible role information includes the publisher which is “kalsoom”, supporting systems and dependents.

  author: kalsoom
  description: Install provided windows package
  company: NG Pvt Ltd

  license: license (GPL-2.0-or-later, MIT, etc)

  min_ansible_version: "2.9"

  - name: Windows

Creating role_main.yml Playbook:

In this playbook, we will pass the name of the role which we initially created along with the host. We will also gather the information related to the hosts. The following is the command used to create the playbook in Ansible:

[root@master ansible]# nano role_main.yml
      ansible_user: ansible
      ansible_password: ******
      ansible_connection: winrm
      ansible_port: 5986
      ansible_winrm_server_cert_validation: ignore

After that, we will now run the statement to get the desired output in the terminal:

[root@master ansible]# ansible-playbook role_main.yml –i host.yml


The concept of roles and how to construct a role in Ansible was covered in this article. The roles’ hierarchical structure has been also covered. Every directory that was stored under the role was explained in detail. To comprehend how roles are used in Ansible, we have additionally developed an example.

About the author

Kalsoom Bibi

Hello, I am a freelance writer and usually write for Linux and other technology related content