So friends, now that we have an idea of how to create our host variables,
let's now dive in to the intricacies of creating our group variables.
Now we already mentioned that with respect to the host files, we would have to
create a directory called host_vars
and for the creation of group variables, we will have to specify a group_vars
directory.
Now inside of this directory, we're once again going to create files with the .
YML extension
and the name of the files, this time as opposed to correlating to the name of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and the name of the files, this time as opposed to correlating to the name of
the individual host in the inventory,
we're going to correlate to all of the groups within the inventory.
Now right now, the only group we have is the all group, so we're going to have
a file called all.yaml,
but if in the inventory, perhaps you may be creating a USA group.
Once again, inside of the group_vars directory, you could create a USA.YML file
as well.
So in the inventory, if we go in, like I say, we could create this USA
and maybe see the blue box in the USA.
By virtue of this being present here within the square brackets in the INI WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
By virtue of this being present here within the square brackets in the INI
format,
Ansible will look for a USA.YML file within the group_vars directory.
This is how this is going to operate.
So for now, what I will do is I will just delete this because we don't actually
need this right now.
Let's just leave the all group.
And the first thing I really want to highlight here about the group variables
is that we have to understand the order of priority here.
Now by default, Ansible is going to look for an all group that's going to
comprise of all of the hosts in the inventory.
We have defined this in our inventory already.
And this particular group with this naming convention all is at the lowest WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this particular group with this naming convention all is at the lowest
priority.
Basically, because it is the widest group, it includes all of the devices
within the inventory.
This is the least specific group.
To help you understand this concept, let's actually consult the Ansible
documentation.
If you just happened to search for organizing host and group_vars, let's go to
this particular link,
how to build your inventory.
And if we just scroll on down, check this part right here.
We're talking about how variables happen to be merged. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now right now, this is going to be the order of operation.
Pretty much we're looking at the lowest priority all the way to the highest
priority.
The way to remember this is that the more specific a variable is the higher the
priority is.
What do I mean by say that we'll think about it in some cases, you may have
variables defined
at different levels within the inventory.
So let's maybe say in the all.yaml file, you happen to have the test for key.
Well, who's that going to apply to?
It's going to apply to all of the devices in the inventory because that is what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's going to apply to all of the devices in the inventory because that is what
the all group is.
Whereas if you happen to define the same variable, test for in this case, in a
general parent group,
this will actually override the value for all devices in that group as opposed
to those devices
getting that value as defined in the all.yaml file.
Similarly, moving on down, if we happen to have a child group of a particular
parent,
if the same variable is defined there, once again, test for any members of the
child group WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is going to get that particular variable value overriding what was defined in
the parent.
As I say, as we get more and more specific, we have a higher priority.
And at the highest level of priority, if there is a clash between any of the
group variables
and a particular host variable, if that variable is defined at the host level,
once again,
such as test for the device will take the value as defined in its host variable
file
because it is the most specific.
Now right now, because we have a very, very simple inventory, we just have one
group called all. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
group called all.
Let's look at the answerable documentation to see information whereby we have a
more detailed inventory.
So let's just scroll up here.
Here we can see an inventory in yaml format, which is absolutely valid.
And above, we can also see the same inventory as specified in i and i.
So let's imagine for now, within our all.yaml file, we simply had a variable
simply defined as DNS_server, okay?
And the value of that was 1.1.1.1.
Now, virtue of this being in the all group, this means if we happen to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, virtue of this being in the all group, this means if we happen to
reference the double-color braces
with the DNS server variable, every device in the inventory is going to get the
value 1.1.1
when it comes to a DNS server.
However, some devices here say, for example, in the Atlanta group, this is
going to comprise of host 1 and host 2.
Let's say in the Atlanta.yaml file, we have the exact same variable to find,
DNS_server,
but the value here is 2.2.2.2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That means the devices host 1 and host 2, when it comes to render their
variable value,
they are not going to get all the ones, they are going to get all the tools,
and all the other devices will still get 1.1.1.1.1.
Now, let's maybe say that host 2, however, within the host var directory,
inside of the host 2.yaml file,
if that actually has the same key defined once again, DNS_server, with the
value 3.3.3.3.3, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this particular host is going to get the 3.3.3 value because its host variable
value will override its group membership.
Now, one last thing to say, in fact, let's just look at this in the yaml format
because it is actually easier to look at in terms of visually,
when I'm talking about a parent group versus a child group.
As we can see here, we have a USA group, an example here, and we have a child
group called Southeast,
as well as Northeast, Northwest, and Southwest.
Basically, if there's a clash between the files in Southeast versus the USA,
Southeast is a child, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Southeast is a child,
so the Southeast.yaml file, the value in that particular file is going to
override the USA.yaml file.
Going further again, if the same variable is defined in, say, for example,
rally.yaml,
we can see rally is indeed a child of Southeast, so rally would override
Southeast as well.
Therefore, the host belonging to this particular group, in this case here, host
to and host 3,
they would get the value from rally.yaml unless, like I say, they happen to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
they would get the value from rally.yaml unless, like I say, they happen to
have it defined personally in their own host variable file.
That is the order of operation.
Now, we can see here, in this case here, we have Atlanta and rally, and they're
both at the same indentation level.
One is not a child of the other.
Now, in this case here, we actually don't have any hosts that belong to both of
these groups,
but you can conceptualize a world, in which case a device belongs to multiple
groups at the same indentation level.
The way Ansible is going to resolve this behavior is it's going to effectively
flatten and merge these files, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
flatten and merge these files,
and it's going to do this on the basis of ASCII order with the last group
winning.
So, let's imagine we have a group called a group, and another group called a
group.
They are at the same level of indentation, and in the group-vars directory, we
're going to have an a-group.yaml file,
as well as a b-group.yaml file.
If we have a clash, which one is going to win, well, because the b-group will
be processed last, because of alphabetical order,
the b-group here is actually going to take priority.
That is how we're going to resolve any of these potential clashes. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
That is how we're going to resolve any of these potential clashes.
But for now, let's get hands on and begin creating some group variables.
So, what we're going to do, I'm going to create this directory called group_v
ars,
let's just cdin, and all I'm going to do is create a file named after every
group in our inventory,
which in this case here is only the all group, so we have all dot.yaml.
So, let's go in here.
Let's have a variable called dnsserver, and I will just give this the address
of 8.8.8.8,
and if I go back and I just copy my var playbook, and I'll just call this var WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and if I go back and I just copy my var playbook, and I'll just call this var
play2.yaml,
and if we go in and edit this particular playbook, all I'm going to do is I'm
going to echo in
the dnsserver variable, and I'll write it into a file called dnstest.ok.
So, right now, if I run this particular playbook, and to enter, we can see we
have a change
on both of our devices, let's go and test.
So, we're in the 10th directory, if I do an LS, we can see we have this dnstest
file,
if I cat open the file, and to enter, we can see the value for blue box is 8.8.
8.
It got that value because of its membership to the all group, and thus took the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It got that value because of its membership to the all group, and thus took the
value directly
from the all dot.yaml file when we called the variable.
Similarly, no surprises when we go to the yellow box.
As we can see, the file is also here, let's just cat open.
Once again, we get the exact same value, now the interest and thing, like I say
, if we happen to have a clash,
and let's go into the host var directory, say for example, and let's maybe go
into the yellow box.
Okay. So, what I'm going to do is, inside of here, I'm going to have the exact
same key dns_server,
but I'm going to give it a completely different value. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's go with 2.2.2.2.2. Okay.
So, let's write this out. We can see when it comes to yellow box, we have 2.2.2
.2, but it also has membership to the all group,
which specifies the variable should be 8.8.8.8.
As you should suspect, when it comes to this clash, which key is going to be
called for that particular device,
the more specific value is going to win, thus we should actually see.
For the yellow box, the value should change to 2.2.2.2.2.
So, let's go and check that out, then let's go back, clear the stream.
We will rerun the same playbook, this time with the updated var files. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We will rerun the same playbook, this time with the updated var files.
As we can see, we have written the change.
We go to the blue box, cat dns_test, no surprises there, it still gets 8.8.8.
However, when we go over to the yellow box and we cat this file again, notice
it now gets 2.2.2.2.2.
This here is an example of the inheritance model prioritizing the variable with
the more specific value.