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 Active/Passive Redundancy mode installation as part of an upgrade. Users who want to deploy Tower in a Redundant configuration should back up their Tower database, install a new Redundant configuration on a different VM or physical host, and then restore the database. It is possible to add a primary or secondary instance later on to Tower if it is already operating on an external database. Refer to the Active/Passive Redundancy chapter of the Ansible Tower Administration Guide.
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
If you are not yet using a 2.4.x version of Ansible Tower, do not attempt to upgrade directly to Ansible Tower 3.0. You must start with a system which has a version of Tower 2.4.x installed or the upgrade will fail.
You must upgrade your Ansible Tower 2.4.4 (or later) system to Ansible Tower 3.0 before you can upgrade to Ansible Tower 3.1.0.
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.
Note
Please note that an issue was discovered in Tower 3.0.0 and 3.0.1 that prevented proper system backups and restorations.
If you need to backup or restore your Tower v3.0.0 or v3.0.1 installation, use the v3.0.2 installer to do so.
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/
root@localhost:~$ tar xvzf ansible-tower-setup-latest.tar.gz
root@localhost:~$ cd ansible-tower-setup-<tower_version>
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 3.3.7 or 3.4.0 directory.
Note
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/.
Note
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:
http://docs.ansible.com/
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
Note
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.