In order to highlight the interest of using roles, I suggest you to use the alemorvan/patchmanagement role, which will allow you to perform a lot of tasks (pre-update or post-update for example) during your update process, in only a few lines of code.
You can check the code in the github repo of the role here.
With this role, you can add your own tasks for all your inventory or for only your targeted node.
Let's create tasks that will be run before and after the update process:
Create the custom_tasks folder:
mkdircustom_tasks
Create the custom_tasks/pm_before_update_tasks_file.yml (feel free to change the name and the content of this file)
---
-name:sampletaskbeforetheupdateprocess
debug:
msg:"This is a sample tasks, feel free to add your own test task"
Create the custom_tasks/pm_after_update_tasks_file.yml (feel free to change the name and the content of this file)
---
-name:sampletaskaftertheupdateprocess
debug:
msg:"This is a sample tasks, feel free to add your own test task"
And launch your first Patch Management:
ansible-playbookpatchmanagement.yml
PLAY[StartaPatchManagement]*************************************************************************
TASK[GatheringFacts]**********************************************************************************
ok:[192.168.1.11]
TASK[Includepatchmanagement]**************************************************************************
TASK[alemorvan.patchmanagement:MAIN|LinuxPatchManagementJob]************************************
ok:[192.168.1.11]=>{"msg":"Start 192 patch management"}
...
TASK[alemorvan.patchmanagement:sampletaskbeforetheupdateprocess]********************************
ok:[192.168.1.11]=>{"msg":"This is a sample tasks, feel free to add your own test task"}
...
TASK[alemorvan.patchmanagement:MAIN|Wecannowpatch]**********************************************
included:/home/ansible/.ansible/roles/alemorvan.patchmanagement/tasks/patch.ymlfor192.168.1.11
TASK[alemorvan.patchmanagement:PATCH|Tasksdependsondistribution]********************************
ok:[192.168.1.11]=>{"ansible_distribution":"Rocky"}
TASK[alemorvan.patchmanagement:PATCH|IncludetasksforCentOS&RedHattasks]**********************
included:/home/ansible/.ansible/roles/alemorvan.patchmanagement/tasks/linux_tasks/redhat_centos.ymlfor192.168.1.11
TASK[alemorvan.patchmanagement:RHELCENTOS|yumcleanall]******************************************
changed:[192.168.1.11]
TASK[alemorvan.patchmanagement:RHELCENTOS|Ensureyum-utilsisinstalled]**************************
ok:[192.168.1.11]
TASK[alemorvan.patchmanagement:RHELCENTOS|Removeoldkernels]*************************************
skipping:[192.168.1.11]
TASK[alemorvan.patchmanagement:RHELCENTOS|Updaterpmpackagewithyum]****************************
ok:[192.168.1.11]
TASK[alemorvan.patchmanagement:PATCH|InludetasksforDebian&Ubuntutasks]***********************
skipping:[192.168.1.11]
TASK[alemorvan.patchmanagement:MAIN|Wecannowreboot]*********************************************
included:/home/ansible/.ansible/roles/alemorvan.patchmanagement/tasks/reboot.ymlfor192.168.1.11
TASK[alemorvan.patchmanagement:REBOOT|Reboottriggered]********************************************
ok:[192.168.1.11]
TASK[alemorvan.patchmanagement:REBOOT|Ensurewearenotinrescuemode]****************************
ok:[192.168.1.11]
...
TASK[alemorvan.patchmanagement:FACTS|Insertfactfile]*********************************************
ok:[192.168.1.11]
TASK[alemorvan.patchmanagement:FACTS|SavedateoflastPM]*****************************************
ok:[192.168.1.11]
...
TASK[alemorvan.patchmanagement:sampletaskaftertheupdateprocess]*********************************
ok:[192.168.1.11]=>{"msg":"This is a sample tasks, feel free to add your own test task"}
PLAYRECAP**********************************************************************************************
192.168.1.11:ok=31changed=1unreachable=0failed=0skipped=4rescued=0ignored=0
Pretty easy for such a complex process, isn't it?
This is just one example of what can be done using roles made available by the community. Have a look at galaxy.ansible.com to discover the roles that could be useful for you!
You can also create your own roles for your own needs and publish them on the Internet if you feel like it. This is what we will briefly cover in the next chapter.
Roles allow you to do away with the need to include files. There is no need to specify file paths or include directives in playbooks. You just have to specify a task, and Ansible takes care of the inclusions.
The structure of a role is fairly obvious to understand.
Variables are simply stored either in vars/main.yml if the variables are not to be overridden, or in default/main.yml if you want to leave the possibility of overriding the variable content from outside your role.
The handlers, files, and templates needed for your code are stored in handlers/main.yml, files and templates respectively.
All that remains is to define the code for your role's tasks in tasks/main.yml.
Once all this is working well, you can use this role in your playbooks. You will be able to use your role without worrying about the technical aspect of its tasks, while customizing its operation with variables.
Let's implement this with a "go anywhere" role that will create a default user and install software packages. This role can be systematically applied to all your servers.
Congratulations! You are now able to create great things with a playbook of only a few lines.
Let's see the use of default variables.
Create a list of packages to install by default on your servers and an empty list of packages to uninstall. Edit the defaults/main.yml files and add those two lists:
Obviously, there is no limit to how much you can improve your role. Imagine that for one of your servers, you need a package that is in the list of those to be uninstalled. You could then, for example, create a new list that can be overridden and then remove from the list of packages to be uninstalled those in the list of specific packages to be installed by using the jinja difference() filter.