Why is developing Ansible Playbooks using Roles a best practice?

Question

It's a best practice to develop Ansible Playbooks with reusable roles.

From what I've seen, people end up putting all their roles into a single complex files anyways. So it doesn't really fix the problem there. I've read they can be split into multiple files, but now there's more to manage and it's no better than just writing multiple playbooks.

Especially considering you can reuse playbooks and tie them together with an Ansible Tower Workflow, I'm not seeing the benefit of including an additional layer of abstraction and complexity for roles.

Can someone tell me if I'm crazy for thinking this?

EDIT:

I've had some more thoughts after reading Bruce's answer.

1. I don't want to be converting Ansible-Galaxy roles into playbooks, or make people I share with turn playbooks into roles.

2. Not everyone I share or collaborate with has access to Tower.

3. Testing

Answer 1

There are many reasons that using roles is better than using long playbooks, and very few reasons that using a single long playbook is better than using a role. These are almost always clear only at a certain scale. Team size, workload number and complexity and frequency of execution all come into play here and the larger any of them get, the more obvious it becomes that organising things hierarchically and modularly into roles is the right thing to do.

From the Ansible docs, there is an emphasis on re-usability:

Roles are ways of automatically loading certain vars_files, tasks, and handlers based on a known file structure. Grouping content by roles also allows easy sharing of roles with other users.

This is also why Ansible Galaxy is potentially useful. One can summarise the effect of a long list of tasks, into a single concept - a role. Although the role may be considered as simply a long list of tasks -- and so not that different from a playbook -- the main benefit comes from the way it scopes variables. Out of the several analogies which may be applied, one may use the Object Oriented analogy. A role is like a class. The usage of that role, applied in a playbook, is like the instantiation of a class into an object. If you consider object-oriented programming useful, you will consider object-oriented infrastructure provisioning useful.

For me, however it comes down to testing. A playbook is tactical and is useful in specific situations. A good role is strategic and is written to solve general problems. Since good roles are modular, they should contain unit tests for various scenarios to prove to the downstream user that they do indeed solve the more general problem, as well as making it clear what is actually covered in the tests.

Typically roles should be maintained, with proper documentation:

• what variables do they use ?
• what scenarios are they written for?

and wide coverage:

• several base operating systems
• several deployment scenarios (docker, AMIs, bare-metal, etc)

and organise tasks cleanly:

• use tags
• dynamically import tasks based on execution conditons and user-provided variables

etc.

In short, I wouldn't consider it a fair comparison to compare a bunch of playbooks with the usage of different roles. When it comes time to refactor your playbooks into something maintainable, you will need roles.