Ansible Tower and Automation Hub have converged to offer a unified platform experience called, Ansible Automation Platform. Starting with Ansible Tower 3.8, what used to be the Tower installer can now install Automation Platform as a whole. Refer to Installing Ansible Automation Platform for further detail.
Automation Platform requires Ansible 2.9. Ansible 2.9.x will be the only supported version installed on Tower 3.8.
Starting with Ansible Tower 3.8, Automation Hub will act as a content provider for Ansible Tower, which requires both an Ansible Tower deployment and an Automation Hub deployment running alongside each other. Tower and Automation Hub can run on either RHEL 7 or 8, but only Tower (not Automation Hub) is supported on an OpenShift Container Platform (OCP).
Starting with Ansible Tower 3.8, you must have valid subscriptions attached before installing the Ansible Automation Platform. A valid subscription needs to be attached to the Automation Hub node only. Other nodes do not need to have a valid subscription/pool attached. See Attaching Subscriptions for detail.
Newly created configurations for inventory sources will contain the default plugin configuration values. If you want your newly created inventory sources in 3.8 to match the output of a 3.7 source, you must apply a specific set of configuration values for that source. To ensure backward compatibility, Tower uses “templates” for each of these sources to force the output of inventory plugins into the legacy format. Refer to Supported Inventory Plugin Templates in the Ansible Automation Platform Installation and Reference Guide for each source and their respective templates to help you migrate to the new style inventory plugin output.
If you need to access a HTTP proxy to install software from your OS vendor, ensure that the environment variable “HTTP_PROXY” is set accordingly before running
The Tower installer creates a self-signed SSL certificate and keyfile at
/etc/tower/tower.key for HTTPS communication. These can be replaced after install with your own custom SSL certificates if you desire, but the filenames are required to be the same.
Installing Automation Platform automatically installs the necessary versions of Node.js to run the Tower User Interface.
Installing Automation Platform or later will install a newer version of rsyslog than what shipped with RHEL. See the Tower Logging and Aggregation section of the Ansible Tower Administration Guide guide for more detail.
It is not recommended that you install Tower using service accounts (PostgreSQL, Redis, etc.) that get authenticated through Active Directory (AD) or LDAP.
If using Ansible version 1.8 or later, ensure that fact caching using Redis is not enabled in
ansible.cfg on the Tower machine.
Note that the Tower installation must be run from an internet connected machine that can install software from trusted 3rd-party places such as Ansible’s software repository, and your OS vendor’s software repositories. In some cases, access to the Python Package Index (PyPI) is necessary as well. If you need to be able to install in a disconnected environment and the bundled installation program is not a solution for you (refer to Using the Bundled Ansible Automation Platform Installer), please contact Ansible via the Red Hat Customer portal at https://access.redhat.com/.
If installing Tower on OpenShift, refer to OpenShift Deployment and Configuration.
Flags and/or extra variables that you can use with the Ansible Tower installer include (but are not limited to) the following:
Usage: setup.sh [Options] [-- Ansible Options] Options: -i INVENTORY_FILE Path to ansible inventory file (default: inventory) -e EXTRA_VARS Set additional ansible variables as key=value or YAML/JSON i.e. -e bundle_install=false will force an online install -b Perform a database backup in lieu of installing -r Perform a database restore in lieu of installing -k Generate and distribute a new SECRET_KEY -h Show this help message and exit Ansible Options: Additional options to be passed to ansible-playbook can be added following the -- separator
-- separator to add any Ansible arguments you wish to apply. For example:
./setup.sh -i my_awesome_inventory.yml -e matburt_is_country_gold=True -- -K
The following table shows some extra variables that can be used during the installation of Tower.
When installing Tower make sure Ansible is also up to date
When installing Tower also create the Demo Org, project, credential, Job Template, etc.
When installing from a bundle where to put the bundled repos
Disable HTTPS traffic through nginx, this is useful if offloading HTTPS to a load balancer
Disable HSTS web-security policy mechanism
Port to configure nginx to listen to for HTTP
Port to configure nginx to listen to for HTTPS
Where to place the backup from setup.sh -b
A temp location to use when backing up
Specify an alternative backup file to restore from
The minimum RAM required to install Tower (should only be changed for test installation)
The minimum open file descriptions (should only be changed for test installations)
Ignore preflight checks, useful when installing into a template or other non-system image (overrides
The following are examples of common scenarios – be sure to supply your own values appropriate to your specific case.
To upgrade core:
./setup.sh -e upgrade_ansible_with_tower=1
To disable https handling at nginx:
./setup.sh -e nginx_disable_https=true
To specify a non-default path when restoring from a backup file:
./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r
To override an inventory file used by passing it as an argument to the setup script:
setup.sh -i <inventory file>
You may want to consider how to configure your proxies and websockets as part of the installation of Ansible Tower to align the websocket config with your nginx / load balancer configuration. See Proxy Support in the following section of this guide for further detail.
Ansible Automation Platform can run on systems where FIPS mode is enabled, though there are a few limitations to keep in mind:
Only Enterprise Linux 7+ is supported. The standard python that ships with RHEL must be used for Ansible Tower to work in FIPS mode. Using any non-standard, non-system python for Tower is therefore, unsupported.
By default, Tower configures PostgreSQL using password-based authentication, and this process relies on the usage of
CREATE USER is run at install time. To run the Tower installer from a FIPS-enabled system, specify
pg_password in your inventory file. DO NOT use special characters in
pg_password as it may cause the setup to fail:
For further detail, see setup_inventory_file.
If you supply a password in the inventory file for the installer (
pg_password), that password will be SCRAM-SHA-256 hashed by PostgreSQL as part of the installation process.
ssh-keygen command generates keys in a format (RFC4716) which uses the
md5 digest algorithm at some point in the process (as part of a transformation performed on the input passphrase). On a FIPS-enforcing system,
md5 is completely disabled, so these types of encrypted SSH keys (RFC4716 private keys protected by a passphrase) will not be usable. When FIPS mode is enabled, any encrypted SSH key you import into Ansible Tower must be a
PKCS8-formatted key. Existing
AES128 keys can be converted to
PKCS8 by running the following
$ openssl pkcs8 -topk8 -v2 aes128 -in <INPUT_KEY> -out <NEW_OUTPUT_KEY>
For more details, see: https://access.redhat.com/solutions/1519083
Use of Ansible features that use the
paramiko library will not be FIPS compliant. This includes setting
ansible_connection=paramiko as a transport and using network modules that utilize the
ncclient NETCONF library.
The TACACS+ protocol uses
md5 to obfuscate the content of authorization packets; TACACS+ Authentication is not supported for systems where FIPS mode is enabled.
The RADIUS protocol uses
md5 to encrypt passwords in
Access-Request queries; RADIUS Authentication is not supported for systems where FIPS mode is enabled.
PackageKit can frequently interfere with the installation/update mechanism. Consider disabling or removing PackageKit if installed prior to running the setup process.
Only the “targeted” SELinux policy is supported. The targeted policy can be set to disabled, permissive, or enforcing.
When performing a bundled install, refer to Using the Bundled Ansible Automation Platform Installer for more information.
When installing Ansible Tower, you only need to run
setup.sh, any repositories needed by Tower are installed automatically.
The latest version of Ansible is installed automatically during the setup process. No additional installation or configuration is required.
Ansible Tower no longer supports Ubuntu. Refer to previous versions of the Ansible Automation Platform Installation and Reference Guide for details on Ubuntu.
For OpenShift-based deployments, refer to OpenShift Deployment and Configuration.