The Ansible Tower architecture has several components to consider. So
we have a user interface for Ansible Tower that can be assessed via
the web interface and we also have a RESTful API. So there are three
possible architectures available for Ansible Tower. We have a single
machine with an integrated database, or a single machine with a remote
database.
We also have a high‑availability multi‑machine
cluster, which we will discuss now.
So in addition to the base single‑node installation, Tower offers
cluster configurations to allow users to scale job capacity on what
we know as forks, on nodes horizontally.
This enables you to scale your automation environment
horizontally. So with cluster configuration,
there's no concept of a primary or secondary in a new tower
system, all of these systems are primary. However,
that was not the case with the different versions of Ansible Tower.
So towering clustering distributes jobs across the
cluster, and therefore minimizes the potential of job
execution service outages. For example,
suppose you have an Ansible Tower installation on a three‑node
cluster configuration and the Ansible Tower service and node
becomes unavailable in the cluster.
In that case, jobs will continue to be executed on the two remaining nodes.
So it should be noted that the failed Ansible Tower node needs
to be remediated to return to the supported configuration,
containing the three or more nodes.
Tower clustering provides increased availability by distributing jobs
across the nodes in the cluster. Keep in mind that a failure of a single
node results in a reduced capacity in the cluster.
So now we can scale capacity within the cluster, and with this design we
now have redundancy, along with additional capacity, which really does
allow you to scale automation in your enterprise.
The more nodes in your tower cluster,
the more job execution capacity you have. If you have to run
many jobs simultaneously, adding more nodes to the cluster
let's you run them without queuing.
So before Ansible Tower version .3,
the HA solution was not really a true high‑availability solution. However,
with Ansible version 3.1 onwards, clustering was introduced, and
this replaced the legacy active passive nodes.
So as you know by now,
clustering is the sharing of load between tower nodes or instances, where
each instance acts as an entry point for UI and API access.
So this allows users to install Tower as a cluster install
rather than doing so as an all‑in‑one install.
So this has been further extended in Ansible Tower version 3.2 to allow
grouping of clustered instances into different pools or queues.
So the clustered instance can be grouped into different pools or
queues, and these are known as instance groups.
And in Ansible Tower version 3.3, we now have the support for container‑based
clusters using OpenShift or Kubernetes. For supported instances at the time
of writing with Ansible Tower version 3.8.6, keep in mind that the maximum
supported instances in a cluster is 20.