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.
Please review the Ansible Tips and Tricks from the Ansible documentation. 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.
Note
Playbooks should not use the vars_prompt feature, as Tower does not interactively allow for vars_prompt questions. If you must use vars_prompt, refer to and make use of the Surveys functionality of Tower.
Note
Playbooks should not use the pause feature of Ansible without a timeout, as Tower does not allow for interactively cancelling a pause. If you must use pause, ensure that you set a timeout.
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.
If you have an external source of truth for your infrastructure, whether it is 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.
Note
With the release of Ansible Tower 2.4.0, edits and additions to Inventory host variables now persist beyond an inventory sync as long as --overwrite_vars is not set. To have inventory syncs behave as they did before, it is now required that both --overwrite and --overwrite_vars are set.
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.
Using the “callback” feature to allow newly booting instances to request configuration is very useful for auto-scaling scenarios or provisioning integration.
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.
For a Continuous Integration system, such as Jenkins, to spawn an Tower job, it should make a curl request to a job template. The credentials to the job template should not require prompting for any particular passwords. Refer to AWX CLI Ansible Tower documentation for configuration and usage instructions.
When an LDAP user authenticates in Tower, by default, all user-related attributes will be updated in the database on each log in. In some environments, this operation can be skipped due to performance issues. To avoid it, you can disable the option AUTH_LDAP_ALWAYS_UPDATE_USER. Refer to the Knowledge Base Article 5823061 for its configuration and usage instructions. Please note that new users will still be created and get their attributes pushed to the database on their first login.
Warning
With this option set to False, no changes to LDAP user’s attributes will be pushed to Tower. Attributes will only be pushed to Tower the first time the user is created.