Answers: <p>No, each has a different role and way of working.</p>
  <p>Starting with the easy ones:</p>
  <p>A <strong>playbook</strong> is simply a list of plays.  The highest level of a playbook YAML is a list, and on that list only two things are accepted: a play definition or the keyword <code>import_playbook</code>, which imports a list of plays from another playbook file, as if they were defined in that place of the calling file.</p>
  <p>The playbook is also the only thing that can be called directly from <code>ansible-playbook</code>.</p>
  <p>A <strong>task</strong> is, paraphrasing the <a href="https://docs.ansible.com/ansible/2.9/user_guide/playbooks_intro.html#playbook-language-example" rel="noreferrer">manual</a>, '<em>nothing more than a call to an ansible module</em>'.  That call definition, however, knows nothing of on which hosts it is supposed to run on.</p>
  <p>The <strong>play</strong> is the element that ties tasks to the servers where they'll run.  The key element here is the mandatory keyword <code>hosts</code>.  This is the part of Ansible that tells which hosts are being affected and how.</p>
  <p>So, the structure and behavior is as follows:</p>
  <ul>
  <li>Playbook: the highest level, just a list of plays
  <ul>
  <li>Play: ties tasks to host lists
  <ul>
  <li>Tasks: definition of a call to a module</li>
  <li>Besides tasks, a play may have pre-tasks, post-tasks and handlers, which are all task-like, and roles.</li>
  </ul>
  </li>
  </ul>
  </li>
  </ul>
  <p>A <strong>role</strong> is a different thing, as it is not defined within a playbook.  Instead, they each have their own subdirectory under the directory <code>roles</code>.  The objective of roles is to organize things.  So, under the role's subdir, you can find tasks, handlers, files and templates, variables and defaults.  All of these related to that specific role.</p>
  <p>So, roles are an easy way to encapsulate and share Ansible information.  You could have a subdir in <code>templates</code> per task, for example.  But if you wanted to share that task, you'd have to pick the template as well.  With roles, you can just zip the role dir and (almost) everything should be there.</p>
  <p>Like a play, the role defines tasks and handlers.  However, roles do not define on which hosts the role will be run.  So roles must be referenced to from a play.</p>
  <p>Roles can also declare dependencies (that is, references to other roles that need to be run before the declaring one).</p>
  <hr />
  <p><em>PS1. Most of this information is available piecemeal on SO (except for playbooks, I couldn't find a proper definition of that on the documentation or elsewhere in the Internet), but I haven't found a comparison between them all, and it took me some time to figure this all out, so I'm sharing that by answering my own question.</em></p>
  <p><em>PS2. I really don't like the fact that roles are named 'roles'.  It sounds a bit counter intuitive to me.  The word 'role' alone alludes to user roles or server roles, to me.  So something more related to Tower (users) or inventory (servers).  I think the rationale for that naming is that they define 'one of the roles that a server functions'.  Same could be said of plays, but roles are more abstract as they're not tied to specific hosts.  Still, I find that naming confusing.</em></p>
  <p><strong>Edit</strong></p>
  <p>A <strong>handler</strong> functions for the most part just like a task.  However, it is not executed by default, with the other tasks, during the playbook run.  Instead, each individual handler will be executed only if notified by a task.</p>
  <p>On a task definition, the keyword <code>notify</code> identifies the handlers the task wants to notify.  If the task is executed and reports a <code>changed</code> state (not <code>ok</code> nor <code>failed</code>), then the handler will be marked for execution.</p>
  <p>After all roles and tasks have run, each notified handler will be executed, in the order they appear in the file.  Check the <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_handlers.html" rel="noreferrer">docs</a> for details.</p>
  <p>Tasks will always run (unless skipped with <code>when</code>), and are responsible for the actual changes you want to implement.  Handlers will be run only in response to tasks making changes, and are generally responsible for finalization steps (restart or reload a service that has had its configuration changed to make it effective, for example).</p>
  <p>You could probably replicate handlers behavior with tasks, but it is such a recurring pattern that Ansible provides handlers as a helper.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-11-18T12:01:54.903Z
Answers: Please mark the answer as accepted if it answers your question.
Answers: 030
Answers: CC BY-SA 4.0
Answers: 2019-11-19T01:54:00.770Z
Answers: Since I'm answering my own question, the system says I need to wait another 18 hours for that
Answers: caxcaxcoatl
Answers: CC BY-SA 4.0
Answers: 2021-01-22T12:25:12.503Z
Answers: Thank you for this list-up.  Can you expand on what a handler is?  I understand it is task-"like".  How does it differ from a standard task?
Answers: leggewie
Answers: CC BY-SA 4.0
Answers: 2021-01-23T22:07:25.850Z
Answers: one registers(notify in Ansible lingo) for handler when defining a task. Handler then runs when this task is complete - useful for cleaning up, restarting services, etc...
Answers: Vano
Answers: CC BY-SA 4.0
Answers: 2021-01-29T21:33:08.313Z
Answers: Thanks for this but I don't understand how these terms relate to the files as they are in a specific ansible playbook/role.
Answers: Alper
Answers: CC BY-SA 4.0
Answers: 2021-02-05T00:24:26.203Z
Answers: @Alper, I have added a section on handlers.  Hope it helps.
Answers: caxcaxcoatl
Answers: CC BY-SA 4.0
Answers: 2019-11-17T20:37:18.380Z
Answers: 2021-02-05T00:24:01.470Z
Answers: 2021-02-05T00:24:01.470Z
Answers: caxcaxcoatl
Body: <p>Ansible has tasks, roles, plays and playbooks.  </p>
  
  <p>Are those just names for different levels in a playbook organization?  </p>
  
  <p>If not, how, exactly, do they differ from and relate to each other?</p>
  
Tags: <ansible>
Title: Ansible: What's the difference between task, role, play and playbook?
UserDisplayName: caxcaxcoatl
ThreadText: # Ansible: What's the difference between task, role, play and playbook?
  
  (Asked by: username_0 on 2019-11-17)
  
  Ansible has tasks, roles, plays and playbooks.
  
  Are those just names for different levels in a playbook organization?
  
  If not, how, exactly, do they differ from and relate to each other?
  
  **Tags:** ansible
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2019-11-17. Score: 36 | Accepted answer
  
  No, each has a different role and way of working.
  
  Starting with the easy ones:
  
  A **playbook** is simply a list of plays. The highest level of a playbook YAML is a list, and on that list only two things are accepted: a play definition or the keyword `import_playbook`, which imports a list of plays from another playbook file, as if they were defined in that place of the calling file.
  
  The playbook is also the only thing that can be called directly from `ansible-playbook`.
  
  A **task** is, paraphrasing the [manual](https://docs.ansible.com/ansible/2.9/user_guide/playbooks_intro.html#playbook-language-example), '*nothing more than a call to an ansible module*'. That call definition, however, knows nothing of on which hosts it is supposed to run on.
  
  The **play** is the element that ties tasks to the servers where they'll run. The key element here is the mandatory keyword `hosts`. This is the part of Ansible that tells which hosts are being affected and how.
  
  So, the structure and behavior is as follows:
  
  * Playbook: the highest level, just a list of plays
    + Play: ties tasks to host lists
      - Tasks: definition of a call to a module
      - Besides tasks, a play may have pre-tasks, post-tasks and handlers, which are all task-like, and roles.
  
  A **role** is a different thing, as it is not defined within a playbook. Instead, they each have their own subdirectory under the directory `roles`. The objective of roles is to organize things. So, under the role's subdir, you can find tasks, handlers, files and templates, variables and defaults. All of these related to that specific role.
  
  So, roles are an easy way to encapsulate and share Ansible information. You could have a subdir in `templates` per task, for example. But if you wanted to share that task, you'd have to pick the template as well. With roles, you can just zip the role dir and (almost) everything should be there.
  
  Like a play, the role defines tasks and handlers. However, roles do not define on which hosts the role will be run. So roles must be referenced to from a play.
  
  Roles can also declare dependencies (that is, references to other roles that need to be run before the declaring one).
  
  ---
  
  *PS1. Most of this information is available piecemeal on SO (except for playbooks, I couldn't find a proper definition of that on the documentation or elsewhere in the Internet), but I haven't found a comparison between them all, and it took me some time to figure this all out, so I'm sharing that by answering my own question.*
  
  *PS2. I really don't like the fact that roles are named 'roles'. It sounds a bit counter intuitive to me. The word 'role' alone alludes to user roles or server roles, to me. So something more related to Tower (users) or inventory (servers). I think the rationale for that naming is that they define 'one of the roles that a server functions'. Same could be said of plays, but roles are more abstract as they're not tied to specific hosts. Still, I find that naming confusing.*
  
  **Edit**
  
  A **handler** functions for the most part just like a task. However, it is not executed by default, with the other tasks, during the playbook run. Instead, each individual handler will be executed only if notified by a task.
  
  On a task definition, the keyword `notify` identifies the handlers the task wants to notify. If the task is executed and reports a `changed` state (not `ok` nor `failed`), then the handler will be marked for execution.
  
  After all roles and tasks have run, each notified handler will be executed, in the order they appear in the file. Check the [docs](https://docs.ansible.com/ansible/latest/user_guide/playbooks_handlers.html) for details.
  
  Tasks will always run (unless skipped with `when`), and are responsible for the actual changes you want to implement. Handlers will be run only in response to tasks making changes, and are generally responsible for finalization steps (restart or reload a service that has had its configuration changed to make it effective, for example).
  
  You could probably replicate handlers behavior with tasks, but it is such a recurring pattern that Ansible provides handlers as a helper.
  
  > **Comments:**
  > **username_1**: Please mark the answer as accepted if it answers your question.  
  > **username_0**: Since I'm answering my own question, the system says I need to wait another 18 hours for that  
  > **username_2**: Thank you for this list-up.  Can you expand on what a handler is?  I understand it is task-"like".  How does it differ from a standard task?  
  > **username_3**: one registers(notify in Ansible lingo) for handler when defining a task. Handler then runs when this task is complete - useful for cleaning up, restarting services, etc...  
  > **username_4**: Thanks for this but I don't understand how these terms relate to the files as they are in a specific ansible playbook/role.  
  > **username_0**: @username_4, I have added a section on handlers.  Hope it helps.  
  
  ---
  
  