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). On Tuesday, May 15, 2018 at 2:25:00 PM UTC-5, Brian Coca wrote: > > 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 Coca > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/e7b34d72-b001-4cbc-a3c5-8e8e0ac9678f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
