In July, we released Ansible Tower 3. This blog series is a deep dive into some of the new aspects of Tower. We've reworked Tower to make it simpler and easier to automate your environments and share your automation solutions. For a complete overview of the Tower 3 updates, check out this post by Bill Nottingham, Director of Product.
Installer configuration in Tower
Before we look at what's new, let’s remember the < 3.0 installer - referred to hereafter as the legacy installer. The legacy installer configuration was designed to be ran by users without Ansible knowledge.
This requirement led to the two step process:
./configure prompts the user for the needed configuration information to setup Tower. This includes things like: tower mode (i.e. single machine, remote database, HA), ssh connection information, and service passwords. The Ansible variable file, tower_setup_conf.yml, is generated to be consumed by the ./setup.sh script.
tower_setup_conf.yml admin_password: password database: internal pg_password: BQgA2Z43jv86dzjDEswH7K75LAwufzSXbE7jUztq primary_machine: localhost redis_password: S3tab7QfWe2e92JEB9hNNFUunV4ircg3EdRdjpxP
./setup.sh wraps the Ansible install.yml, backup.yml, and restore.yml playbooks and passes in the appropriate run-time flag to include the previously generated configuration variable file and manage the generated logs. The ./setup.sh script also solves the bootstrapping chicken and egg problem of installing Ansible and of detecting and handling our bundle install.
What's new in Tower 3
With the installer in Tower 3, we now assume that you already have some Ansible knowledge. Continuing to try and cover all connection and authentication scenarios through a decision tree driven by command line prompting is an error prone and lengthy process for the user. Instead, we got rid of ./configure, and now allow the user to directly use Ansible’s robust connection methods and authentication specification through host variables. This allows users to, for example, setup a redundant Tower system with secondary nodes that have different ssh username/password combinations than the primary.
How do I configure my Tower 3 install?
Through the inventory all group variables, Tower can be installed in three modes:*
- Monolithic Tower
- Remote Database Tower
- Redundant Tower
The decision tree below shows how we detect which of the three modes the configuration is setup for.
*There is a 4th sort of configuration mode. Tower 3 installer will setup a remote PostgreSQL instance, when configured. We will go over this later in this blog post.
1. Monolithic Tower
Below is the inventory file that ships with Tower. Users are required to fill in the password variables: admin_password, redis_password, pg_password.
# 1. Monolithic Tower [primary] localhost ansible_connection=local [secondary] [database] [all:vars] admin_password='' redis_password='' pg_host='' pg_port='' pg_database='awx' pg_username='awx' pg_password=''
2. Remote Database Tower
Example configuration intended to set up a Tower instance with a remote PostgreSQL database such as RDS.
# 2. Remote Database Tower [primary] t-db-primary [secondary] [database] [all:vars] admin_password='password' redis_password='password' pg_host='test-db-db' pg_port=5432 pg_database='awx' pg_username='awx' pg_password='password'
3. Redundant Tower
Example redundant Tower configuration with one primary Tower node, two secondary Tower nodes, and an existing remote PostgreSQL database specified.
# 3. Redundant Tower [primary] t-database-primary ansible_ssh_user=ec2-user [secondary] t-ha-secondary-1 ansible_ssh_user=ubuntu t-ha-secondary-2 [database] [all:vars] admin_password='password' redis_password='password' pg_host='t-ha-postgres' pg_port=5432 pg_database='awx' pg_username='awx' pg_password='password'
Other Tower 3 installer changes
Removing the ./configure prompting step is the most user-facing change made to the Tower installer. There are a few more user-facing changes and less-user-facing changes added to the installer. Specifically:1. Removed munin
This one is pretty obvious, one less password to configure.
2. Setup remote DB node
Tower 3 will install and configure PostgreSQL for use by Tower on a dedicated machine.
Previously, we required that the user install and configure their remote PostgreSQL instance. Separating the Tower instance from the database instance can be useful for managing compute and storage resources. Simply adding a host to the [database] group will trigger a remote PostgreSQL install during the tower installer process.
# 2. Setup remote DB node [primary] t-db-primary [secondary] [database] test-db [all:vars] admin_password='password' redis_password='password' pg_host='test-db' pg_port=5432 pg_database='awx' pg_username='awx' pg_password='password'
3. Desired state pattern of Ansible applied to changing of passwords
In keeping with the desired state pattern of Ansible, changing admin_password, redis_password, or pg_password and running the install Playbook on an existing Tower 3 machine will result in the respective password changing.**
Previously, these values were the current passwords needed by the installer Playbook. Now, the installer does not need the current password.
** We will not change a remote PostgreSQL instance password.
4. Fail fast
We’ve expanded the set of pre-flight checks that the installer already had (disk space, memory check, fd limit, umask settings, log permissions, etc.) to include the new configuration setup. Specifically, early in the Playbook we ensure: all required hosts specified for tower install mode, connection + authentication + privileges on all hosts, all needed passwords specified.
Try the simplified Ansible-based installer now
The simplified Ansible-based installer for Tower is built with the user in mind. Whether you're installing all-in-one or installing a redundant configuration with a remote PostgreSQL instance, the new installer has it covered.
Ansible Tower 3 is available now for anyone to try via local install, Vagrant image, or AMI. Just click here to get started with the latest version of Tower today.