In this demo,
we're going to navigate the Ansible demo objects that
come with the Tower installation.
We will address the resource section and discuss the
autonomy of an automation job.
You will also get a glimpse of how you may run your first
automation job and all of the objects needed.
So on the left we have RESOURCES,
which is probably one of the main areas you're going to be working in.
Here we have Templates, Credentials, Projects,
Inventories, and Inventory Scripts.
So let us click on Inventories just to see what we
have here with a fresh install.
So as you know, the inventory is the main building block,
and this tells Ansible Tower what it needs to manage so Ansible
can keep the desired state of the target assets.
Here we simply have a Demo Inventory as I did not create this,
and here we have the demo resources that exist from the install.
So the only thing in this Demo Inventory worth noting is that
under the HOSTS section we just have localhost,
which is the Ansible Tower managing itself.
Now let's have a look at Credentials.
The credentials are the credentials to use to determine how
you're going to connect to the managed hosts that you have in
your Ansible Tower environment, which are specified in your inventory files.
So these are the credentials that are used to
connect to what you want to manage.
So here we click on Demo Credential, and we have the name Demo Credential,
but also notice we have a credential type of Machine.
Machine credentials are the default, and you'll be seeing this in later demos.
We also have a number of different credential types that are
available depending on what we want to connect to and what
type of inventory we're using.
We have VMware vCenter, OpenShift, machine that we just discussed,
which is a default type, Google Compute Engine,
and AWS.
Notice we have a username of admin,
and this username must exist in the managed host you want to manage,
and it doesn't need to exist as a user on the Tower host itself.
It's just a default user from the install and does
not need to exist on the host,
but we can quickly check this by looking at the following location.
So once you have your credentials set up, you need to move on to your projects.
So the role of the project is to reference your playbooks.
So the project specifies what you want to do.
So here we have a Demo Project.
We have a name, the organization it belongs to, and the SCM details.
So this Demo Project is all about connecting to a repository,
and here we set the URL, which is set to ansible‑tower‑sample.
What I like about Ansible Tower is that it's good at working well
with contact management systems such as GitHub,
which makes it a lot easier to work with dispersed managed teams.
Here you can see we have a green light, which is next to the project.
Here,
we're just checking in with the repository to see if
there's any updates to the playbooks.
As you can see on the right‑hand side, we have a changed status of 0,
so we have no new updates for this project.
Also notice that the JOB TYPE is set to Check.
Then we moved to Templates,
and this really is the glue and what ties everything together.
As you can see, we have a Demo Job Template.
Here we have a template name and also a job type of Run.
There is also a Check option here,
and this will be like running a dry test on your
playbooks with the CLI commands.
And this is similar to the Check option that I just mentioned before.
But for our test, we'll just put this job type back to Run.
We also have an inventory specified,
and this is a Demo Inventory which is pointing to our localhost and not any
managed host yet because we don't have this configured.
For projects, we also want to specify the project,
and this is the connection to a Git repository which holds all of our playbooks.
And in this case for our demo, we just have a simple playbook called hello_world.
So this playbook was found in the GitHub repository
that Ansible Tower is connected to.
Now for the final piece of the puzzle, we want to launch our project.
So here we select on LAUNCH.
As you can see, this opens up a new screen, and we have two main areas.
In the DETAILS section, we have the status of running,
and it also displays the settings that we have in a template,
such as a job type of Run and not Check,
the inventory that we've set, the project that we're using,
and the playbooks we are running along with the credentials that
we are using to connect to the managed hosts.
So this is a pretty small playbook,
and we have a play on the on the right‑hand side,
and we're carrying out the normal playbook stages,
such as running tasks.
The first task is implicit, and this is just gathering facts,
and then it moves on to the next task.
So what you see on the right‑hand side is familiar to what you'd
see if you're running a playbook with the CLI.
So we're just gathering some facts in the localhost, which is done by default.
And you can turn this off if you want to to save time,
or you could even use a fact cache.
Then we're executing a task message, Hello World!
So to execute this task, we need to use an Ansible module,
and here we're using the debug module,
which is similar to the Linux print statement that prints to the screen.