What's New in Tower 3: Installer

September 19, 2016 by Chris Meyers

Ansible-Tower-3-blog-series.png

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:

Step 1:
./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

Step 2:
./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:*

  1. Monolithic Tower
  2. Remote Database Tower
  3. 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.


Share:

Topics:
Ansible Tower, Tower 3


 

Chris Meyers

Chris is the Senior Software Engineer at Ansible by Red Hat, contributing Tower backend APIs. Before Ansible, Chris worked on projects like a mobile food ordering system for stadium concessions and a remote control cat video laser device. To learn more about those you can follow him on Twitter @oldmanmeyers85.


rss-icon  RSS Feed

Ansible Tower by Red Hat
Ansible In-Depth Whitepaper
ansiblefest brooklyn 2016
Learn About Ansible Tower