The recommended approach is to move more towards a platform or a central
point of managing automation. That allows you to enforce standards with
you automation from the top organization level to the exact CLI
arguments that can be run and by who.
Ansible Tower,
also known as Ansible Automation Platform, goes beyond just
running automated playbooks, and it helps you to have control and
visibility of your entire infrastructure.
Ansible Tower can tie multiple processes and actions into a
coherent workflow with a central control point.
This will provide you the necessary safeguards while introducing
you to the more advanced automation use case.
Some of these advanced use cases that we'll be discussing
throughout this course are workflows, job scheduling,
role‑based access control, remote execution,
notification clustering, and REST API access.
So you need to effectively manage automation,
especially when you're moving automation into production, and this is
often referred to as operationalizing automation, and Ansible Tower can
help you with a holistic viewpoint of automation, even from the basic
automation use cases to the most advanced.
Ansible Tower enables developers to check out and provision their
development environments built from scratch and 100% consistent with
the software stack that is used in all of your software release
environments, such as development, testing,
staging, and production, because it is built all from the same playbook.
So when you first started working with Ansible, your team of
users may have been small. You could automate a single stack and
multi‑machine deployments from your laptop that could look after
a large number of servers.
Ansible was a big time saver, and not just for new deployments, but also for
patching servers and orchestrating multi‑machine deployments.
It's not uncommon to find Ansible orchestrating hundreds or even
thousands of machines. You can handle server differences with variables,
and most of the Ansible modules are idempotent. So all of this is good
as long as you only have one or two people that are communicating
regularly about who is doing what and, more importantly, when they are
automating. You don't want people from different teams to automate over
each other.
The infrastructure landscape change was not the only problem as
we have Ansible collections and Ansible roles.
However,
the types of users and their level of technicality changed and
grew. People that have no even basic automation skills, certainly
not advanced skills that would use loops,
variable substitution, and data manipulation with filtering,
they actually need to carry out automation to perform their jobs.
So nowadays, we're looking to expand automation, and not just
to simple application deployments or even the ability to
orchestrate multi‑machine deployments,
but we need to bring automation to an enterprise level. For this,
we need to bring new levels of control, security, and delegation
capabilities to your automation practices.
So to reduce complexity,
automation is a very valuable tool. But with extensibility comes
many challenges that we've just discussed,
particularly for team‑based and larger cross‑departmental usage.
We now have more of a need to deliver holistic automation, and
this can be done with Ansible Tower. Tower allows you to
control access of who can access what,
even allowing sharing of SSH credentials without someone
being able to transfer those credentials.
The inventory can be graphically managed or synced with various
cloud sources. Personally, the provisioning callback feature
has been a great use case to me and provides great support for
autoscaling topologies.
Ansible Tower logs all of your jobs, and this can be
centrally stored with, for example, an ELK stack.
Also, for enterprise authentication,
Ansible Tower can integrate well with, for example,
LDAP and also has a browsable REST API for even the more
custom use cases, which we will demo soon.