Ansible Roles.
An Ansible role is a reusable and standalone component that
encapsulates a set of Ansible tasks and configurations.
Yeah, here's the situation. Each of your playbooks likely does one task.
Well,
I shouldn't use the word task because you know a playbook can consist of
N number of plays and Y number of tasks within each.
But look, the idea is as your infrastructure expands,
broadens, and deepens, you're liable to have multiple playbooks
that need to be applied to the same set of hosts.
The idea of the role is that we can decompose one or more playbooks.
You have to construct the role according to a very rigid framework.
It's not bad though. It makes sense. But the benefit is you're able
to use a single role to apply and manage what otherwise would be an
untold number of separate playbooks.
So a role is a great consolidation factor for us as
Windows configuration management managers.
Some of the other benefits, if I haven't already
mentioned, of using roles is organization,
grouping related tasks for specific functionalities. Reusability is a big
one because the roles are packages that you can upload to Ansible Galaxy for
sharing with your colleagues or maybe with the world. And you can always
share them individually in your network.
All of these are plain text files that should already be under version
control anyway. Maintainability, again, fits in hand and glove.
You can simplify updates.
Instead of having to make an update to a playbook multiple times,
you can make a single canonical update to the tasks that are
within the role. And readability, it enables you to document.
You'll see this actually. You can create a README markdown file
where you can document the role.
And so it's really a self‑contained‑‑‑ I don't want to say unit of work
because I've used that in terms of the playbook before. But I hope you can
immediately see the benefit that roles bring to Ansible.