Now whilst it might appear terribly exciting to be
able to manage your localhost, obviously,
Ansible can do a lot more, but it's going to need some configuration.
We're going to go through and create ourselves a working directory
called ansible and move into that directory.
All of these commands that we are running with Ansible will
be executed from this ansible directory,
The directory name can be anything, it doesn't have to be ansible,
but if we use a configuration file in the directory,
then this configuration file needs to be in the same
directory where we issue our command from.
There are other locations we can put configuration files,
but to keep it simple, we'll just add it into this ansible directory.
We've got one section called defaults, and we're adding in a remote_user.
This is the user account we're going to use to connect to on our remote systems.
Our path through to the inventory, the inventory file then,
should be in the same directory because we haven't put a full path,
a relative path.
So in this working directory,
we're going to have both the configuration file and the inventory.
Host_key_checking being set false just ensures that if
we haven't already got the SSHE keys,
we can go through and download those automatically.
We can check our configuration that is in use by
using the ansible‑config command.
Dump will list absolutely everything.
But if we want to look at only the things that have
changed from the default settings, then we can look at ‑‑only‑changed,
and we should see the three elements being listed.
The inventory file we need to create as well.
This is the list of hosts that we need to manage.
So if we create the inventory file in that same directory,
and there are examples of the inventory and of the Ansible
configuration provided within our Git repository.
We've got our redhat group, and that's going to be the IP address 192.168.56.11.
These are the IP addresses that I've specified within the Vagrantfile.
If you're using other systems,
then obviously make sure you put in the correct IP addresses.
If we notice the Ubuntu system,
we've added in a variable there so we don't make an SSH
connection because we are on that system,
so we can connect as the local user and make a local
connection rather than making an SSH connection.
We can always check the inventory by using the
ansible‑inventory command and ‑‑list.
‑‑Yaml is a tidy output.
Now to be able to test this,
we can go through and make sure we're in that working directory.
We can then run the ansible command with the group all.
This is a built‑in group.
We don't need to define it.
‑K will prompt for the SSH password, and ‑m being the module.
We should get a response then coming back from all of our systems.
To do something a little bit more,
we can really start then testing the strength of Ansible.
Here we've used an extra switch, ‑b, to become, so we elevate our privileges.
We're using the package module,
and this will take arguments because obviously we've got
to say which package we want installed.
We're saying the name of the package is tree,
and we want to make sure that the package is present,
essentially meaning that it's installed.
If these work,
we can be really happy that everything is working the way that we want.
But as always,
the very best way to run our learning is from the command line and to follow through in the demonstrations.