So come on then,
let's go through and find that command line and take a look
at configuring Ansible on our controller,
the Ubuntu system.
We're going to be creating an ansible.cfg,
we we're going to be creating the inventory,
we'll be adding inventory variables, and,
of course, we'll be testing that this works across our three systems.
So here we are on the glorious command line.
We know how glorious that always is.
We're going to create ourselves a subdirectory.
The subdirectory name doesn't really matter.
I don't think that it needs to be called Ansible.
But my Ansible directory then is going to become my working directory
whilst we're going through this module of our course.
The Ansible directory is also available for you within our git repo,
so you can look at samples that I have created.
Now before I go any further,
I'm going to go back to the ansible ‑‑version command,
and when we take a look at the configuration file that's in use,
it's the default location of etc/ansible and ansible.cfg.
Now that file is totally commented,
so all of the defaults will be coming from the Ansible program itself.
Now we know we don't want to work with the
configuration file in the TC directory, we want to create our own.
And one of the options is to create it in our working directory.
So if I go through and vim ansible.cfg, I can go into INSERT,
obviously we can use any editor that we want,
and we can go in and put the default section in.
Underneath here, I'm going to put a few settings, so our remote user.
This represents the user account that we're going to use on our managed nodes.
So we're going to have our remote_user = vagrant.
Now I'm using vagrant for this,
and of course then there is a Vagrant account on each of our systems.
On SUSE and on RedHat‑based systems, we are able to log in via the password.
We can specify our inventory.
The inventory is the list of hosts that we want to manage.
But I'm going to put a relative path,
so it's looking for a file called inventory in my case,
within our working directory.
The other problem we might come across is then having to
accept public keys from the SSH service.
So to automatically accept them, we can go through and put host_key_checking,
and if we set this to false, then we won't care about it,
we'll automatically accept the offered keys.
With this done, I can go through and save it.
If I go through now and just look at my Ansible version,
one thing we should notice now with the config file is that we're picking up
that we've got an ansible.cfg in our current directory,
so it's choosing to use this.
We can also go through and look at the ansible,‑config command,
and if I go through and run this with dump,
it will print out everything.
But if I want to check that my settings are in place,
‑‑only‑c is a nice way of getting to see the settings that you have made.
Now we've made three settings, so I'm expecting to see three entries there.
If I've misspelled any, then they won't show in that list.
Now we also need our inventory,
so I can go through then and edit the file called inventory.
Remember, I gave it that name.
Now I can just put my IP addresses in, so 192.168.56.11,
and then really, we can go through and copy that,
and it's going to be just quickly editing the last digit.
Now again, this is the IP addresses that we're using within the Vagrant file.
If you're using different systems,
then just make sure you've got the correct IP addresses.
Now this is fine, it's going to work,
but it's not going to allow me to access all of my RedHat hosts,
or all of my SUSE hosts, or all of my Ubuntu hosts.
So very often we will then start adding in groups.
Groups are just added in like INI file headings,
so I can go through and specify that we've got let's say a redhat group,
we can specify then that we've got a suse group,
so I can add in then suse,
and we can go through and specify if we want an ubuntu group.
Now, the Ubuntu host is my localhost that is the controller,
so I can add to this a variable so it just then
extends past the name or IP address, either our hostname or IP address,
and then I can go through and specify that we want our ansible_connection.
Instead of being the default, which is SSH,
we want this to equal then a local connection.
Now we have that within our built‑in host,
but as soon as we start using different records for it,
we're going to have to add those settings back.
Once I'm ready with this, I can save that,
and I can go through and run my ansible‑inventory command ‑‑list,
and a YAML format is a nice tidy output to look at.
And we can see then that we've got our three hosts.
Only the IP address 13 has the variable,
but we can see then that we've got groups redhat,
suse, and ubuntu, but we also have a built‑in group called all.
Now we're going to make use of that group.
If I use ansible all,
I want to go to all the hosts. We can use ‑k because we need
to prompt for our password to connect, and use the m for our module,
and the same module we used before, the ping module.
We're being prompted for our password, it's vagrant if we
are using Vagrant, and we can then go through and see that
we're getting a green response,
so a good response coming back from each of our hosts.
There is just a little bit of a warning saying that we might want to
hard code our location of the Python interpreter,
but we're getting a response so it's working.
Now, of course, the Ping module is very good,
it can show that we've got connectivity; however,
we really want to do a little bit more, don't we?
So if we go through now and run ansible,
again targeting the all group so we can access everything within our inventory,
‑k we know is going to then prompt for the SSH password,
but additionally we're using b to become elevate our privileges.
By default, that's going to be using sudo on our Linux systems.
We can use the package module to look at installing and removing software.
This is now going to require arguments, so ‑a, and
then quote your list of arguments.
One of the arguments we're going to have to provide is the name of the package.
So we're going to say tree, and we're going to say that we want this installed,
so we'd say state=present. We've really got present or absent.
We can also use latest to make sure we've got the latest available. Again,
running through and adding in our Vagrant password, we're able then to go
through and see that we're installing the software on all three systems.
And it doesn't matter that the three systems are different Linux systems,
it is the package module itself choosing the correct packager on the
target system.
Now with that done and it's installed on all systems,
I can go back and run exactly the same command again and demonstrate
what's called idempotency, in the fact that if we meet the desired
state, then we don't do anything, we don't error,
we just say good,
we meet the required state. And that's really what we're able to
see here where everything is coming back green, whilst we wait for
the third system to come in. But yeah,
now the third system has come back in that we meet the
desired state that has nothing to do.
There is one more option that we can look at by adding in the ‑o for 1, so
lowercase o. We get one line of output per host, so this can make it easier
to read. As we then go through and take a look,
we can see then our green messages coming back.
It's wrapping on multiple lines, but it is essentially one line per host.
Now that we know how to run our configuration using ad hoc commands, let's
look at something similar using Playbooks, so we're able to repeatedly run the configuration