In this course,
we're going to go through the key components of
Ansible Tower and its functionality,
which is considered a considerable step up from the Ansible CLI
that you may have used with Ansible Core.
We will discuss the changes in today's landscape,
such as the team‑based approach to automation.
That is driving a holistic approach.
That needs to be more manageable and secure.
We will also discuss the autonomy of an automation job,
which shares similar objects when using the CLI,
but has considerable differences, such as job templates,
along with more advanced features that make it easier to
introduce automation to the enterprise.
We will discuss advanced features such as job scheduling,
API access, notifications, and surveys.
We will also go through the high availability options you
have with Tower, such as clustering, along with the
clustering best practices and basics.
There will be a lot of demos in this course, around eight.
These will range from preparing your environment for Ansible Tower install to
the more complex setting up smart inventories and navigating the API. We will
start this module by addressing the challenging landscape that is causing a
lot of challenges and problems when automating with Ansible Core and the CLI.
To operationalize your environment and move automation into production, you
really do need to have everything centrally managed with better role‑based
access.
Not everyone needs the keys of the kingdom.
We will address how to run an automation job and the main objects
used, such as projects that are collection of playbooks, inventories
that you're probably aware of, and job templates that glue
everything together. In this module,
there will be three demos. The first demo will be preparing
your environment for an Ansible Tower install.
The second demo will be navigating the demo objects that come with the
fresh install. And the final demo will be creating a new automation job
using the main Tower objects. In smaller team environments where
everyone is well versed in Ansible, maintaining control over automating
the infrastructure and adhering to Ansible best practices in terms of
using playbooks,
meeting your security requirements, and delegation of control is manageable,
but challenges surface as teams start to scale, and the use case of
automation becomes diverse. Many organizations now have a team‑based usage
needs that stretch well beyond the Ansible command line interface with
Ansible Core. During software development,
software goes through a series of stages.
Generally, the further away from production,
the less the environment looks the same.
These differences range from software library versions, configuration
settings, and authentication details. All of this will deviate even more
over time as the popularity of automation increases, and how can we
control this by using the CLI‑based version of Ansible Core? So we know
that the biggest barrier to innovation is complexity, and to overcome
this obstacle,
many organizations are looking for automation to introduce
simplicity and the less siloed environment.
However, if the role of automation is not properly managed,
this power comes at a considerable price.
If everyone in every team has a copy of Ansible on their local machines,
how can this be controlled to determine even the basics of auditing and
logging in the sense of who ran what playbook and when? So how do you
ensure that all playbooks are correctly stored and version controlled?
When running a playbook, it's recommended you have them stored in a
source control management system,
but it's not a mandatory requirement, and Ansible commands and playbooks
can be stored and run from individual laptops. When running a playbook from
the CLI, once a particular task has been run, we have an output to the
screen, but the output is lost forever.
We have the capability to turn on login for Ansible,
similar to how we potentially can store playbooks in the
source control management system.
However, these need to be enforced, and they need to be enforced centrally.
So how do we enforce such rules of automation among different users with
cross‑departmental automation use cases? I'm sure there will be a Linux team
with playbooks and a network team with network playbooks.
So how do you prevent superuser‑level access credentials being given across your
organization? Ansible, given its nature and typical use cases, which is
deployment, is often given the keys of the kingdom in the form of SSH keys and
passwords that have root or other administrative level‑privileges, so you need
to enforce policy. That can be difficult with many operators having root access
to a given Ansible machine.
So finally, to streamline your automation workflow,
let's say you want to trigger an Ansible job from another job.
In this case, you would want to use an API or in cases where a
person that should trigger a job should only be able to trigger
that specific job with workflow approval.
So as you can, see when it comes to advanced use cases such as
triggering jobs based on events or automating job scheduling,
the CLI is not the best tool and does not have much control in the sense of
role‑based access on these particular advanced features.