In this demo, we're going to create your first automation job.
We will address all of the Ansible objects needed and go into
additional details to the autonomy of an automation job.
So no changes have been made since the first demo,
so the dashboard remains the same.
So first, let me check the etc/hosts file,
and this will give you an idea of the environment we have.
As you can see, we have a relatively small environment with three hosts.
One host is Ansible Tower, and the other two hosts tower1 and tower2,
are the managed hosts based on the rocky distribution.
So I've done a couple things in the background just to speed things up,
and currently I've copied my SSH keys to tower1 and tower2.
And then on each of the managed hosts, tower1 and tower2,
we have a target user called pluralsight1. So you know that the
inventory is the main building block for Ansible, so let us start
here. And there are a number of different inventory types we can
have. We can have a static inventory,
a dynamic inventory. And if you have a dynamic inventory, it can
prepopulate variables from, for example, AWS.
So you are keeping up to date with everything you have
launched on the AWS side of things.
We can, if we want, integrate our hosts into an existing
inventory. But for this demo, I would like to create a new
inventory by clicking on the green plus symbol.
We have the option of Inventory and the Smart Inventory.
We will be creating a normal inventory. In comparison, a smart
inventory uses a special filter that looks at specific facts, such
as a distribution, to add hosts to the inventory, and we'll be
looking at this in later demos.
So now, let us go to Inventory. and we create inventory.
We're also in the Default organization, and we'll give it a description.
So now we need to add hosts, so we click on HOSTS, and
then we go to add hosts in the inventory.
So I'll type tower1 and click SAVE, and then I'll simply
type tower2, and then I'll click on SAVE.
So now we should have tower1 and tower2 in our inventory.
So for this example, I just added the name tower1 and tower2 as I
know I can reach out to these machines as I have them, A, in my
etc/hosts file, but I also did a quick ping test before I started
the demo. It's a good idea just to ping my name to test resolution
before you add hosts.
So in our case, resolution and connectivity from the
tower to the managed host is good.
So now that I've got the two hosts added to my inventory,
let me go back to the inventory and check that they
have been successfully added.
However,
as you can see, I just have one host of tower2 and not
tower1. Honestly, Ansible can be a little bit tricky in the
sense that when you make change,
you need to click on SAVE, but you also need to exit the
screen and go back in and add the second host.
So let me quickly do this, and I'll start everything from
scratch, and then we'll go back into the inventory just to
check that the settings are correct.
So when you're adding hosts, there's nothing really else you want to do.
Just remember to click on SAVE after each host you add and not to
override the host that you've just typed in.
Also, at this stage,
I'd just like to point out permissions and is that we can specify
permissions, and this will allow you to connect your host to specific
users to allow access to a specific group of users.
Just make sure you add the user account to Ansible Tower first.
Now, let us move to the Credentials section.
So these are the credentials that Tower uses to manage the hosts.
So the credentials are the Ansible objects that we use to authenticate
to the managed machines in the Tower environment.
We also have to select organization. Even though it's the Default,
we still need to click on the magnifying glass.
The credential type we're using is Machine, and you
may recall this from the first demo.
This really is the most important property to add. The Machine type is needed to
authenticate to the managed machines of tower1 and tower2.
So this will open up a different window option, and then on page three of this
window option, we will select a credential type of Machine.
So we have other options on this page, and we can, for example,
enter the SSH keys or the username and password.
In our case, we're going to put in the username of pluralsight1,
which is the user I've already added, and I'm going to enter the password.
We could, if we wanted, enter prompt on launch for the password.
Just keep in mind that I've already created this user for us in the
background on the two managed hosts of tower1 and tower2. At the moment, we
don't really need this, but we do want privilege escalation on the
PRIVILEGE ESCALATION METHOD, and we set this to sudo. So the PRIVILEGE
ESCALATION METHOD is sudo, and we also need to set the PRIVILEGE ESCALATION
USERNAME, and this will be root.
So here I will enter my privilege escalation password, and I
have not configured sudo to be working without a password, and
this is why I need to enter this here.
So by doing so, we are integrating privilege escalation
into the Ansible Tower environment, and we don't need to
configure passwordless sudo.
So this configuration that we're doing now is potentially
more secure than using passwordless sudo.
So now we need a project, and our project can be connected in a
number of ways. And you may recall that you can have all your
projects locally on the Tower machine,
but in our case, our project corresponds to a Git repository where all of our
playbooks are stored and version controlled. If you want,
you can add a manual and then refer to the manual directory, but it's
much better to have a project on, let's say, GitHub, and here we can
specify the URL to the GitHub repository.
So if you have different Git repositories,
you will need to have different projects.
So it's one Git repository per project.
Next, we select the green button next to our project to make sure
that we can connect to the GitHub repository.
Now we're at our final step, and this is the creation of a job template.
So up until now, we have an inventory, which is the main building block.
We also have our credentials set up, which are used
to connect to the managed hosts.
We also have a user account that's connected on the managed host that I
created. And we also have a project, and this project links to our GitHub
repository where we have the playbooks held.
So next, we need to have a template, and here we're
going to create a job template.
A workflow template is more complicated, and we
will look at this and later demos.
So for now, we just need a simple job template.
Consider a job template to be the equivalent of a playbook.
It's just like a preconfigured playbook run.
So for the job template details, we're going to be creating a singular job,
and we'll give it a name. We'll call the inventory that we set and the project,
which is the project where all of our playbooks are. So a template
connects to a project, and the project is connected to our GitHub
account, and this is where our playbooks are stored.
So this is just the start of the course, and I've got a small deployment, so I
only have one playbook at the moment, and it's a really simple playbook just
for demo purposes that's installing a package.
Just keep in mind that playbooks are hard coded, and
in my host set I will have tower1,
but if I had a playbook set to run on a host that was not in my inventory,
it would not run successfully.
Tags are also a feature, and they really are good for playbook development.
They allow you to tag different parts of the playbook, and then you can
run different parts of the playbook based on the tag.
So you don't need to run all of the playbook when you're working
through playbook development, and this is really,
really good when you have multiple teams that are working on the same
playbook. We also have extra variables, so the playbooks need to be working
here, and you want to make sure that playbooks are never too specific. So you
want to use variables as much as you can, and this will remove site‑specific
information from the playbook.
We also have a number of options on the bottom right of the screen.
We have privilege escalation that you're aware of by now. We've
got provisioning callbacks that we'll look at later, webhooks,
concurrent jobs, and fact cache,
all of which we'll look at later, and these are optional. Here, we
just need to set privilege escalation so the commands in the task in
our playbook are able to run as root user.
So keep in mind about the fact cache. In fact, gathering can be really,
really time consuming,
especially if you're using smart inventories that we'll demo later.
So now that we've launched we will start the playbook, and you
can see we have an error that's displayed immediately. It's not
too much of a serious error, it's just a YAML syntax, so I'll go
back and I'll fix that.
But remember that when you're making changes to the
GitHub repository and your playbooks,
it's a really good idea to go back and manually sync your project by
selecting the green button next to the project that you're working on. Now
we'll try to launch again, and as you can see, this one's been successful,
and it's automatically entered the SSH password so we can connect to the
managed hosts, and then it's entered the become password so we can become and
have the correct privileges to perform the playbook activities, which is
running a set of tasks.
Now, let us go back to the main page, and you can see we have some
differences than we first had at the start of demo.
We now have three hosts, for example. We started this module by
addressing the challenging landscape that are causing,
let's say, challenges when automating with Ansible Core
and just the CLI. To operationalize your environment and
move automation to production,
you really want to have everything centrally managed
with better role‑based access control.
We also addressed how to run an automation job and the main objects used,
such as projects, which are a collection of playbooks,
inventories, and job templates that glue everything together.
In this first module, there were three demos.
The first demo was all about preparing your environment for Ansible Tower.
The second was navigating the demo objects that come with a fresh install.
And then the final demo that we just had was to create a brand‑new
automation job using the main Ansible Tower objects.