Ansible Roles
Ansible roles provode a framework so that you will have an
organized structure of your projects that you are implementing
to target hosts.
It basically organize and package Ansible playbooks and
associated files into reusable and modular units. It allows
you to encapsulate specific tasks, configurations, and
dependencies for a particular component or function within
your infrastructure. This modular approach makes it easier
to manage and maintain your Ansible codebase.
Here's an example to illustrate Ansible roles:
Suppose you have a apache web server infrastructure with
multiple servers, and you want to ensure consistent
configurations across all of them. You can create an Ansible
role for configuring the web server.
So you can create required folders for a specific roles or you
can use below command which will give you structured folders
required for your project.
# ansible-galaxy init apacheThis command will create a directory structure like this:
apache/
├── defaults/
│ └── main.yml
├── files/
├── handlers/
│ └── main.yml
├── meta/
│ └── main.yml
├── tasks/
│ └── main.yml
├── templates/
├── tests/
│ ├── inventory
│ └── test.yml
└── vars/
└── main.ymlBelow are some details for above folders:
tasks: It contains all tasks files (Playbooks related tasks)
vars: It contains all vars which we need inside our project.
files: Any kind of text/files/codes/config files
handlers: It contains handlers tasks by defining notifier.
templates: It have all jinja2 files used for project.
defaults: It is also used for declaring variable. High value
is default that vars.
meta: It contains role information. (Author name/dependency/OS
requirement etc.)
Now we will implement apache on target hosts and you can see
all contents required to implement apache.
# tree apache/
apache/
├── defaults
├── files
│ └── code
│ └── index.html
├── handlers
│ └── main.yml
├── meta
├── tasks
│ ├── fw.yml
│ └── main.yml
├── templates
│ └── web.conf.j2
└── vars
├── main.yml
└── path.ymlBelow is the actual "main.yml" which will perform your task.
# cat apache/tasks/main.yml
- name: Install apache
yum:
name: "{{ websvc }}"
state: installed
- name: Start httpd
service:
name: "{{ websvc }}"
state: started
enabled: true
- include_vars: path.yml
- name: Copy developer page
copy:
src: code/
dest: "{{ webroot }}"
- name: Copy jinja file
template:
src: web.conf.j2
dest: "{{ apache_config }}"
notify: apache_restart
- import_tasks: fw.ymlDefined Variables, Templates, defaults:
You can define variables in the vars/main.yml file and use
templates in the templates/ directory to make your role more
flexible and customizable. In above example, I have defined
variables and templates.
# cat apache/vars/main.yml
websvc: httpd
# cat apache/vars/path.yml
webroot: /var/www/html
# cat apache/templates/web.conf.j2
<Virtualhost {{ ansible_default_ipv4.address }}:80>
ServerName {{ ansible_hostname }}
Documentroot {{ webroot }}
</virtualhost>
# cat apache/defaults/main.yml
apache_config: /etc/httpd/conf.d/web.confHandlers:
# cat roles/apache/handlers/main.yml
- name: Restart apache webservice
service:
name: "{{ websvc }}"
state: restarted
listen: apache_restartIn the handlers/main.yml file, you can define handlers that are
triggered when specific events occur.
Meta Information:
The meta/main.yml file can contain metadata about your role,
such as author information and role dependencies.
Using the Role in Playbooks:
After creating the role, you can use it in your Ansible
playbooks by specifying the role's name and run it to
implement your project:
# cat roles/playbooks/role-apache.yml
- hosts: all
gather_facts: true
roles:
- apache# ansible-playbook roles/playbooks/role-apache.yml
PLAY [all] **********************************************************************************************************************************************
TASK [Gathering Facts] **********************************************************************************************************************************
ok: [managed2.kb.com]
ok: [managed1.kb.com]
ok: [alma.kb.com]
TASK [apache : Install apache] **************************************************************************************************************************
ok: [managed2.kb.com]
ok: [managed1.kb.com]
ok: [alma.kb.com]
TASK [apache : Start httpd] *****************************************************************************************************************************
changed: [managed2.kb.com]
changed: [managed1.kb.com]
changed: [alma.kb.com]
TASK [apache : include_vars] ****************************************************************************************************************************
ok: [managed1.kb.com]
ok: [managed2.kb.com]
ok: [alma.kb.com]
TASK [apache : Copy developer page] *********************************************************************************************************************
changed: [managed2.kb.com]
changed: [managed1.kb.com]
changed: [alma.kb.com]
TASK [apache : Copy jinja file] *************************************************************************************************************************
changed: [managed2.kb.com]
changed: [managed1.kb.com]
changed: [alma.kb.com]
TASK [apache : install firewalld] ***********************************************************************************************************************
ok: [managed2.kb.com]
ok: [managed1.kb.com]
ok: [alma.kb.com]
RUNNING HANDLER [apache : Restart apache webservice] ****************************************************************************************************
changed: [managed2.kb.com]
changed: [managed1.kb.com]
changed: [alma.kb.com]
PLAY RECAP **********************************************************************************************************************************************
alma.kb.com : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
managed1.kb.com : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
managed2.kb.com : ok=8 changed=4 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0By using Ansible roles, you can easily reuse and share
standardized configurations for specific components or
functions across your infrastructure, making your Ansible
playbooks more modular and maintainable. It is also not server
dependent, it can easily ported to other server from where you
can run things.