Variables allow you to separate code from the site‑specific configuration.
A DevOps best practice is to allow configuration as code.
So in general, variables allow you to develop flexible code.
In the playbook, if you are too specific,
you need to maintain an abstraction layer and keep out this
very specific information from your playbooks.
Variables are defined by you,
and facts are generally dynamic and then you can use them in your playbooks.
This decoupling allows you to use the playbooks and only the
things you need to change are the variables.
In this demo,
we will start by keeping variables in a separate file from the playbook.
So with the myvar.yaml file,
we are simply referencing a php package to be installed.
In this file, you can see we have defined the key value style.
We can also use the any style, which is a key equals value style.
Now let us check the actual playbook,
and I've created a playbook called variables.
Then under tasks,
you can see we're installing a package where the variable has to be substituted.
Then we have the vars_file which points to the file that I've just created.
So there are many different ways to call variables.
You could also use the var prompts.
This can be used to prompt users for the variables,
and this variable is then flagged as private,
but you can change this to private no if need be.
So to use fact gathering, we can use the setup module,
and this is an ad hoc command.
As you can see,
the return is pretty extensive and it may be hard to
find exactly what you're looking for.
It would be much easier to run a filter against specific parts of this variable.
This will return exactly back what you need, instead of this extensive list.
So because Ansible collects so many facts,
this setup module supports a filter parameter that lets you filter,
for example, by name or by a specific job.
The filter option only filters level subkeys below ansible_facts.
So in our example, we're going to filter just for the IPv6 addresses.
So we can manually gather facts, and we can also read them from a text file.
So as you can see,
all these facts are stored in one large variable called ansible_facts,
and within this variable, we have what's known as second tier variables,
and these variables have their own value.
So these facts are variables, and then we can use these facts in,
for example, conditionals.
Next, let us check out another playbook.
So here, fact gathering is implicit,
but we can also call this variable ansible_facts to
display all facts with the debug module.
Next, let's edit this playbook so we can specifically look for specific facts.
Here,
we're just going to call for all IPv4 addresses so this
will display just the IPv4 addresses of the host that we're
running this playbook against.
So facts are stored as multivalued variables with the name ansible_facts,
which is organized like a dictionary.
So in larger environments, you may want to speed up fact gathering.
You can use a fact cache, but if you use a fact cache,
there may be a chance that some of your facts may be out of date.
So first, let us look at the time command, which is a Linux command.
Here, you can see the real time, user time, and system time.
Now let us change the playbook just to run in the localhost to
see if there are many deviations in the times.
As you can see, it's just slight.
If fact gathering is taking too long,
you really want to make sure that your host
resolution is performing as expected.
This could certainly delay things.
So here,
we can use Ansible to check the etc.host file and make
sure that the settings are correct.
My file looks pretty good as it's just a small deployment with just a few hosts.
However, if there was an issue,
you could use the Ansible copy module to copy over the etc/host file
from the control host to all the managed hosts.
And a more advanced level,
you could delegate this task such as delegate the copy module
for a specific host to copy their etc file to the host that
don't have correct etc/host files.
We'll be looking at this in the next module.