- All right, for this lab,
we are going to start with the working version
of Ansible Tower.
Makes no sense to install it again.
We are going to add the CentOS 7 machine
that I just installed.
Okay, let's do a quick test
and see if we can log in.
As I say, Ansible at 192.68.29.195.
And yes and (indistinct).
And also sudo ls /root.
Is that working?
Prompting for a password,
but we are getting in.
So we have privilege escalation,
and seems to be good.
So let's get to the Ansible Tower interface.
In the Ansible Tower interface,
I am going to use my inventory,
and in the inventory,
well, it's up to you what you want to do.
You can integrate it into an existing inventory.
I don't wanna do it.
I want to create a new inventory
to make this a separate topic.
So the name is CentOS 7
and the organization is default.
Well, before I can do anything,
I need to click on safe.
Next I need to add my hosts,
and my hosts are centos7.example.com.
Just one host.
One more thing.
We need to get back to the command line
and sudo VIM on ATC hosts to make sure
that we actually can reach out to this machine.
So 192.168.29.195 on centos7.example.com.
Short name, as well.
There we go.
Now that we are on the command line,
we should also wonder,
do we need to do anything else?
Well, this is Ansible Tower,
so you don't necessarily have to copy over
SSH keys and stuff.
So we are done with the inventory.
Let's continue with the credentials.
So in the credentials,
I'm adding new credentials.
We call it sent credentials.
The organization is going to be my default organization,
and the credential type.
It's the most important property.
That will be the machine credentials.
There we go.
Then it's asking for username and password.
So anyhow, it's getting this from cash.
I need a new password.
You have a choice here between SSH keys and password.
SSH keys is convenient from the command line
but you might also want to use a password.
Depends on your security setting.
An important one is the privilege escalation method.
I need to set privilege escalation to sudo
and a privilege escalation per username.
That will be root and a privilege escalation password.
That will be my very secret root password.
The nice thing about this is
by using this manual privilege escalation
integrated into Ansible Tower,
I don't need to configure any passwordless sudo.
So I kind of like this.
This makes it more secure, right?
Then we have the projects.
That's just staying the same because we are
in the same git repository.
Might need to to do an update every now and then.
That's also something that you might need to do
while working with Ansible to make sure
that you have access to the latest
and greatest YAML files.
Then we are going to configure a template.
So that's my job template.
That's just a singular job, CentOS job,
and it's a run,
and the inventory is CentOS 7.
Here we go.
Then the product is my default product,
and the playbook.
Do we have any nice playbook?
run and test httpd.
That's what we were asked for in the lab.
And next we have the credentials.
So in the credentials, we have these sent credentials,
and then I'm doing my select and that should do it.
Now, there is one thing to realize,
and that is the playbook.
The playbook is hard coded with a host name.
So if this playbook is doing a host all,
then it will be all right.
If this playbook is doing a host something specific
which is not sent to S7,
then it is not going to be alright.
Let's figure out if that is working,
and if it's not working, let's fix it.
I mean, this is part of what you will find
in reality while working with Ansible Tower itself.
There we go.
This is what I was afraid of.
Could not match supplied host pattern, ignoring rocky.
So how are we going to fix that?
Well, there are two options.
Option number one, you are going to fix it in the playbook.
That will probably be the best option because,
well, the problem here is really in the playbook
and we want the playbook to be running
in the Ansible Tower environment.
Option number two, we could do a dirty trick
and in the inventory define a group with the name rocky.
If we have a group with the name rocky,
then it will work in this environment, as well.
You know what?
I feel like doing the dirty trick.
In the end, It's really up to what you wanna do,
but I'm just going to create a new group
with the name Rocky.
And I hope you sense
that this is not a really a perfect solution.
But if we add this group rocky, there we go.
Then we add the host, existing host,
and that will be sent to us at example.com.
We add that to the group.
We get back to the template.
We run the CentOS 7 template's job again.
And there we go.
And you can see that,
well, it is reaching out.
We see install, start,
and enable HTTP
and install packages working on the package insulation.
All of this depends on the quality
of the playbook, of course,
because in playbook development,
you can develop your playbooks
in such a way that it easily will work
across different distributions by using packets
and by using flexible host names
that are easy to reuse.
If the playbook is too specific,
then it won't work.
And oh, what are we getting here?
I am getting message.
You need to be root to perform this command.
Aha.
That's nothing that depends on the playbook.
You need to be root to perform this command.
That depends on something else,
and this something else is quite common.
Let me explain why this is a common error.
If you look at the credentials,
we have our sent credentials,
and in the sent credentials,
I've told it to do privilege escalation.
And why doesn't that work?
Well, that doesn't work because you need to specify that
on the job template, as well.
So let me get back to the CentOS job
and let me tick this option,
enable privilege escalation to ensure that it will work
with privileged escalation.
I'm saving.
And I am launching again.
And here we go.
Now it should be doing something.
So as you can see, it's progressing.
The package is installed
and everything else should be doing all right, as well.
If it fails at this point,
it's due to the quality of the playbook,
not due to Ansible Tower.
So for now, let's consider this lab completed successfully.
Uh-oh, there's only one thing that is failing here.
And there we go.
You can see it's telling us status code was minus one,
name or service, not known.
Why do we have name or service not known?
Well, doing an http://rocky is trying to reach out to Rocky.
The name of my machine is not Rocky.
It's CentOS 7.
You cannot reach a host based on the Ansible group name.
That's a minor problem in the playbook.
Nothing wrong with Ansible.
So let's continue with the next lesson.