playbooks and tasks

I was reading the thread "VMware - convert template to virtual
machines" and when I saw Nick's structure I realized I do have a lot
to learn conceptually about ansible. Specifically having playbooks and
roles separated. I always thought that the tasks inside roles were
considered playbooks.

How does that work?

playbook => contains plays

play => maps hosts to tasks

roles => reusable content, can be vars, templates, files, tasks, etc

task => action to perform on a host

playbook does get overloaded as it is both an object and a file that
contains plays, but files that contain just tasks (task lists) are
many times also called playbooks, but they really are not.

Brian states things the way we define them.

I broke things up that way for a few reasons:- Development process: Our dev team works in a similar fashion with their code base, and objectifying the infrastructure Ansible is controlling in a similar way lets the dev team use my Ansible work on their environment copy and they can change installation requirements for test/prod as needed in one role, for example. Wrap all that up in the sprint/peer review/merge process, and it’s pretty slick. They get to learn how things should be properly deployed, I get to learn coding best practices. Win-win.

  • Isolation: Once I have a role narrowed down specifically enough, I rarely look at the task(s) again. This keeps me from modifying an existing role for a new environment that adversely affect other environments. I heavily use inventory grouping mapped with playbooks to keep track of what tasks to run where (some of that falls down from the development process, a similar concept to branching).
  • Future-proofing: Putting a single module in a role’s individual files allows me to look at the Ansible changelog and quickly refactor affected tasks during our Ansible upgrades. The con here is that I have a lot of playbooks that are just 20 lines of ‘import_playbook’ and ‘include_role: tasks_from’ - which isn’t necessarily intuitive from a playbook maintenance perspective. But the above pros of development and isolation win over that con (for us).

Whether the way I’ve demonstrated in my GitHub is the right way is not certain, but it makes sense in my head. Ansible appears to be quite flexible, and there’s a lot about Ansible I don’t fully grok yet, so if there are better ways to do things, I’m open (PR’s are open on that project).