12. Best Practices¶

12.1. Use Source Control¶

While Tower supports playbooks stored directly on the Tower server, best practice is to store your playbooks, roles, and any associated details in source control. This way you have an audit trail describing when and why you changed the rules that are automating your infrastructure. Plus, it allows for easy sharing of playbooks with other parts of your infrastructure or team.

12.2. Ansible file and directory structure¶

Please review the Ansible best practices from the Ansible documentation at http://docs.ansible.com/playbooks_best_practices.html. If creating a common set of roles to use across projects, these should be accessed via source control submodules, or a common location such as /opt. Projects should not expect to import roles or content from other projects.

Jobs run in Tower use the playbook directory as the current working directory, although jobs should be coded to use the playbook_dir variable rather than relying on this.

12.3. Use Dynamic Inventory Sources¶

If you have an external source of truth for your infrastructure, whether it’s a cloud provider or a local CMDB, it is best to define an inventory sync process and use Tower’s support for dynamic inventory (including cloud inventory sources and custom inventory scripts). This ensures your inventory is always up to date.

12.4. Variable Management for Inventory¶

Keeping variable data along with the objects in Tower (see the inventory editor) is encouraged, rather than using group_vars/ and host_vars/. If you use dynamic inventory sources, Tower can sync such variables with the database as long as the Overwrite Variables option is not set.

12.5. Autoscaling¶

Using the “callback” feature to allow newly booting instances to request configuration is very useful for auto-scaling scenarios or provisioning integration.

12.6. Larger Host Counts¶

Consider setting “forks” on a job template to larger values to increase parallelism of execution runs. For more information on tuning Ansible, see the Ansible blog.

12.7. Continuous integration / Continuous Deployment¶

For a Continuous Integration system, such as Jenkins, to spawn an Tower job, it should make a curl request to a job template, or use the Tower CLI tool. The credentials to the job template should not require prompting for any particular passwords. Using the API to spawn jobs is covered in the Tower API guide.