For many projects, a simple, single Ansible playbook may suffice. As time goes on and projects grow, additional playbooks and variable files are added, and task files may be split. Other projects within an organization may want to reuse some of the content, and either the projects get added to the directory tree or the desired content may get copied among multiple projects. As the complexity and size of the scenario grows, something more than a loosely organized handful of playbooks, task files, and variable files is highly desired. Creating such a hierarchy can be daunting and may explain why many Ansible implementations start off simple and only become more organized once the scattered files become unwieldy and a hassle to maintain. Making the migration can be difficult and may require rewriting significant portions of playbooks, which can further delay reorganization efforts.
In this chapter, we will cover the best practices for composable, reusable, and well-organized content within Ansible. Lessons learned in this chapter will help developers design Ansible content that grows well with the project, avoiding the need for difficult redesign work later. The following is an outline of what we will cover:
- Task, handler, variable, and playbook inclusion concepts
- Roles (structures, defaults, and dependencies)
- Designing top-level playbooks to utilize roles
- Sharing roles across projects (dependencies via Galaxy; Git-like repos)