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.
Note
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:
Obtain the Ansible Automation Platform Installation Program and upgrade to Ansible Tower 3.8 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.
Obtain the Ansible Automation Platform Installation Program and install a fresh version of Ansible Tower 3.8 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. Depending on the size of your Ansible Automation Platform installation, this may take some time. 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.
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/.
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.
Note
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.8 on RHEL 8, you must also have Ansible 2.9 or later installed.
Subscriptions from Satellite can be applied to a Tower instance by providing a Satellite username and password with access to subscriptions. To take advantage of this, you must register your Tower node with Satellite by installing the Katello RPM before upgrading to Tower 3.8.x. See Installing Satellite instances on Tower for more information.
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.
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.
root@localhost:~$ ./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: inventory)
-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