# Building a highly available Ansible Tower cluster

With the release of Ansible Tower 3.1 a short while back, it became possible to setup Ansible Tower in a highly available, active-active topology. You do this by setting up multiple Tower nodes that talk to a shared PostgreSQL database on a separate node. This database can be setup and managed by the Tower installation playbook, or you can manage it yourself.

Each of the Tower nodes will serve up the web front end, so your users can choose which Tower server they use to log into. If you change the configuration through the web UI on one node, the change is visible over all instances through the shared database. For example, uploading a Tower license file to one of the Tower instances will make it show up in all of your Tower cluster nodes.

Cluster nodes keep in touch with one another for job scheduling and such through RabbitMQ.

Sounds good? That’s because it is! And it gets better: setting up a Tower cluster is insanely easy!

As an example, I have set up a Tower cluster on three nodes: tower01.nontoonyt.lan, tower02.nontoonyt.lan and tower03.nontoonyt.lan. The database will reside on towerdb.nontoonyt.lan. By configuring the inventory in a specific - and quite simple - way, the Tower installation playbooks will build the whole cluster for me.

The below snippet is an edited version of the special inventory file we ship in the ansible-tower-setup tarball, called "inventory_cluster".

[tower]
tower01.nontoonyt.lan
tower02.nontoonyt.lan
tower03.nontoonyt.lan

[database]
towerdb.nontoonyt.lan

[all:vars]

pg_host='towerdb.nontoonyt.lan'
pg_port='5432'

pg_database='tower'

rabbitmq_port=5672
rabbitmq_vhost=tower

# Needs to be true for fqdns and ip addresses
rabbitmq_use_long_name=true

To invoke setup.sh to perform a cluster installation based on that inventory file, you just run:

# ./setup.sh -i inventory_cluster

That’s it. Hope you enjoy the new Ansible Tower cluster feature! Take a look at the Youtube screencast that goes with this blog.

#### Maxim Burgerhout

Solution architect at Red Hat for the platform and cloud portfolio; likes Python, likes Ruby, internally conflicted about that; maintainer of @RedHatSatellite