<p>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 <strong>hierarchically</strong> and <strong>modularly</strong> into roles is the right thing to do.</p>

<p>From the <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html" rel="noreferrer">Ansible docs</a>, there is an emphasis on <em>re-usability</em>:</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>This is also why Ansible Galaxy is potentially useful. One can summarise the <em>effect</em> 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 <em>usage</em> of that role, applied in a playbook, is like the <em>instantiation</em> of a class into an <em>object</em>. If you consider object-oriented programming useful, you will consider object-oriented infrastructure provisioning useful.</p>

<p>For me, however it comes down to <strong>testing</strong>. A playbook is <em>tactical</em> and is useful in <em>specific situations</em>. A good role is <em>strategic</em> and is written to solve general problems. Since <em>good</em> 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. </p>

<p>Typically roles should be <strong>maintained</strong>, with proper documentation:</p>

<ul>
<li>what variables do they use ?</li>
<li>what scenarios are they written for?</li>
</ul>

<p>and wide coverage:</p>

<ul>
<li>several base operating systems</li>
<li>several deployment scenarios (docker, AMIs, bare-metal, <em>etc</em>)</li>
</ul>

<p>and organise tasks cleanly:</p>

<ul>
<li>use tags</li>
<li>dynamically import tasks based on execution conditons and user-provided variables</li>
</ul>

<p><em>etc</em>.</p>

<p>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.</p>

CC BY-SA 4.0
2019-10-30T17:21:12.803Z
2019-10-30T17:21:12.803Z
Bruce Becker
<p>It's a best practice to develop Ansible Playbooks with reusable roles.</p>

<p>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.</p>

<p>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.</p>

<p>Can someone tell me if I'm crazy for thinking this?</p>

<p><strong>EDIT:</strong></p>

<p>I've had some more thoughts after reading Bruce's answer.</p>

<ol>
<li><p>I don't want to be converting Ansible-Galaxy roles into playbooks, or make people I share with turn playbooks into roles.</p></li>
<li><p>Not everyone I share or collaborate with has access to Tower.</p></li>
<li><p>Testing</p></li>
</ol>

<ansible><configuration-management>
Why is developing Ansible Playbooks using Roles a best practice?
QuestionTime247
# Why is developing Ansible Playbooks using Roles a best practice?

(Asked by: username_0 on 2019-10-30)

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

**Tags:** ansible, configuration-management


---

## 1 answers

### Answer by username_1 on 2019-10-30. Score: 6 | Accepted answer

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](https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html), 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.


---

