You can upgrade your existing Tower installation to the latest version easily. Tower looks for existing configuration files and recognizes when an upgrade should be performed instead of an installation.
As with installation, the upgrade process requires that the Tower server be able to access the Internet. The upgrade process takes roughly the same amount of time as a Tower installation, plus any time needed for data migration.
This upgrade procedure assumes that you have a working installation of Ansible and Tower.
You can not convert an embedded-database Tower to a Clustered installation as part of an upgrade. Users who want to deploy Tower in a Clustered configuration should back up their Tower database, install a new Clustered configuration on a different VM or physical host, and then restore the database. It is possible to add additional instances later on to Tower if it is already operating on an external database. Refer to the Clustering chapter of the Ansible Tower Administration Guide.
If Tower is on a version of RHEL older than RHEL 8 and you want to upgrade to Ansible Tower on RHEL 8, follow the sequence outlined below:
Get the Tower Installer and upgrade to Ansible Tower 3.7 on RHEL 7
Run Tower Backup included in the Tower setup playbook. See Backing Up and Restoring Tower in the Ansible Tower Administration Guide for details.
Get the Tower Installer and install a fresh version of Ansible Tower 3.7 on RHEL 8
Run Tower Restore included in the Tower setup playbook. See Backing Up and Restoring Tower in the Ansible Tower Administration Guide for details.
This process ensures that the PostgreSQL database is also properly migrated to the latest version if you are upgrading an embedded-database Tower. Note that if you upgrade a Tower with an external database, the client libraries will be upgraded as well, but you will need to upgrade your external PostgreSQL server manually. Be sure the check the release notes to see if this applies to you before upgrading.
Before upgrading your Tower installation, refer to Requirements to ensure you have enough disk space and RAM as well as to review any software needs. For example, you should have the latest stable release of Ansible installed before performing an upgrade.
All upgrades should be no more than two major versions behind what you are currently upgrading to. For example, in order to upgrade to Ansible Tower 3.6.x, you must first be on version 3.4.x; i.e., there is no direct upgrade path from version 3.3.x. Refer to the recommended upgrade path article off your customer portal.
In order to run Ansible Tower 3.5 on RHEL 8, you must also have Ansible 2.8 or later installed.
It is advised that you create a backup before upgrading the system. After the backup process has been accomplished, proceed with OS/Ansible/Tower upgrades.
Refer to Backing Up and Restoring Tower in the Ansible Tower Administration Guide.
You may install standalone Tower or use the bundled installer:
if you set up Tower on an environment with a direct Internet access, you can download the standalone Tower installer
if you set up Tower on an environment without direct access to online repositories, or your environment enforces a proxy, you must use the bundled installer
Download and then extract the Ansible Tower installation/upgrade tool: http://releases.ansible.com/ansible-tower/setup/
To install or upgrade, start by editing the inventory file in the
ansible-tower-setup-<tower_version> directory, replacing
<tower_version> with the version number, such as
As part of the upgrade process, database schema migration may be done. Depending on the size of your Tower installation, this may take some time.
If the upgrade of Tower fails or if you need assistance, please contact Ansible via the Red Hat Customer portal at https://access.redhat.com/.
Ansible Tower 3.0 simplifies installation and removes the need to run
./configure/ as part of the installation setup. Users of older versions should follow the instructions available in the v.2.4.5 (or earlier) releases of the Tower Documentation available at:
The Tower setup playbook script uses the
inventory file and is invoked as
./setup.sh from the path where you unpacked the Tower installer tarball.
[email protected]:~$ ./setup.sh
The setup script takes the following arguments:
-h – Show this help message and exit
-i INVENTORY_FILE – Path to Ansible inventory file (default:
-e EXTRA_VARS – Set additional Ansible variables as key=value or YAML/JSON (i.e.
-e bundle_install=false forces an online installation)
-b – Perform a database backup in lieu of installing
-r – Perform a database restore in lieu of installing (a default restore path is used unless EXTRA_VARS are provided with a non-default path, as shown in the code example below)
./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r
Please note that a issue was discovered in Tower 3.0.0 and 3.0.1 that prevented proper system backups and restorations.
If you need to back up or restore your Tower v3.0.0 or v3.0.1 installation, use the v3.0.2 installer to do so.