So due to latency and potential outage concerns,
the Ansible Tower clusters are not recommended to span data center boundaries.
So deployments that span data centers are not recommended due to
the transient spikes and latency and outages.
So the Tower cluster nodes and databases should be geographically
colocated with low latency and reliable connectivity.
So by organizing your Ansible Tower cluster into a number of instance groups,
each instance group can now have its own job queue,
and any node in that job can take jobs off that queue.
So instances can be grouped into one or more instance
groups to share resources for that purpose.
And jobs can be assigned to instance groups in three ways.
We can do this with organizations, inventories, and job templates.
Therefore the execution of jobs, under those resources,
will favor those particular queues.
So by defining a policy,
you can configure Tower instances to automatically join
instance groups when they come online.
These policies are evaluated for every new instance that comes online.
So an Isolated Node is Ansible Tower node that contains a
small piece of software for running playbooks locally to
manage a set of infrastructure.
You may often find Isolated Nodes behind,
potentially, a firewall or a VPC or even in a remote data center.
So put an Isolated Node in each remote location and then
you can use it for your inventories.
In this case, we're managing inventories just for that remote office,
and so we'll assign the isolated group at that inventory level.
Also for VPCs, again, you've got multiple teams in multiple environments,
but each one is secure in its VPC then you don't want to open all of the
infrastructure in your VPC to your Ansible Tower cluster.
In this case,
you can put a node in each VPC to handle automation for
those environments with the Isolated Nodes.
That way you only need to allow SSH to the Isolated Node
while the remaining VPCs remain isolated.
So each instance in a Tower cluster expands its
cluster capacity to execute jobs.
Jobs can and will run anywhere rather than be directed on where to run,
expanding the cluster and its capabilities.
So each instance in a Tower cluster expands the
cluster's capacity to execute jobs.
So when a job is submitted from the API interface,
it gets pushed into the dispatcher queue.
Each Tower instance will connect to and receive jobs from the queue,
using a particular scheduling algorithm.
So when a job is submitted to the Tower queue,
it can be picked up by any of the workers.
However, you can control whether a particular job runs,
such as restricting the instance on which the job runs.
So Tower supports container‑based clusters using OpenShift.
So Tower pods are configured without HTTP,
and then installer will configure an OpenShift route construct.
The OpenShift route construct enables external access
and also implements security features.
So consider the OpenShift route construct to handle the SSL
termination and then distribute requests to all Tower pods.
So we started this module by highlighting the Ansible Tower best
practices that you should adopt in the enterprise,
such as autoscaling and provisioning callback.
We addressed Ansible Tower and the Jenkins integration.
That really will drive consistency in your enterprise.
We also examined Ansible surveys, schedules,
and notifications that are easy to perform but
considered advanced Tower use cases.
We ended this module by addressing Ansible Tower clustering.
That is best suited for larger enterprise environments.
There were two demos.
We firstly set up a survey,
and then we looked at how to configure notifications along with job scheduling.
So in this course, we went through the Ansible Tower functionality,
which is a considerable step up from just using Ansible CLI
that you may have used with Ansible Core.
We discussed the changes in today's requirements,
such as a team‑based approach to automation.
That is driving more of a holistic approach.
That needs to be more manageable and secure.
We also discussed the autonomy of an automation job,
which shares some of the same objects when using the CLI,
but has additional objects, such as job templates,
along with more advanced features,
which make it easier to introduce automation into the enterprise at scale.
We then addressed the new Ansible objects and advanced features,
such as job scheduling, API access, notifications,
and surveys.
We also went through the high availability options you have with Tower,
such as clustering, along with the clustering best practices.
There were a lot of demos in this course,
around eight,
and they ranged from preparing your environment for Ansible Tower install,
to the more complex Smart Inventories, and navigating the API.