WEBVTT

1
00:00.000 --> 00:04.240
So friends, in this particular video, what I want to discuss with you is the

2
00:04.240 --> 00:05.400
concept of

3
00:05.400 --> 00:07.400
facts within Ansible.

4
00:07.400 --> 00:11.440
So the question is, what exactly are facts and why do we need them?

5
00:11.440 --> 00:17.040
So really at its core, all facts are a kind of special variable, so to speak.

6
00:17.040 --> 00:21.430
And these special variables tell us about the actual hosts that we happen to be

7
00:21.430 --> 00:22.400
managing.

8
00:22.400 --> 00:26.990
So imagine this, here we have our Ansible control node right here, and we have

9
00:26.990 --> 00:27.840
our managed device

10
00:27.840 --> 00:31.880
here or blue box, as well as our yellow box.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:27.840 --> 00:31.880
here or blue box, as well as our yellow box.

11
00:31.880 --> 00:36.240
Now when Ansible goes and makes connections to these managed devices, we have

12
00:36.240 --> 00:36.920
the option

13
00:36.920 --> 00:42.440
to retrieve facts about these devices, i.e. these special variables.

14
00:42.440 --> 00:46.280
So this might include information such as the operating system of the device,

15
00:46.280 --> 00:46.800
which in our

16
00:46.800 --> 00:50.320
case here in both systems happens to be RETA enterprise Linux.

17
00:50.320 --> 00:54.050
But of course, if we happen to be managing more devices, perhaps there may be

18
00:54.050 --> 00:54.760
Ubuntu,

19
00:54.760 --> 00:58.310
or maybe Fedora, that type of thing, but it's not just the operating system, we

20
00:58.310 --> 00:58.560
can

21
00:58.560 --> 01:03.180
also have information relating to the IP addresses on the devices, and a whole
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

21
00:58.560 --> 01:03.180
also have information relating to the IP addresses on the devices, and a whole

22
01:03.180 --> 01:03.920
bunch of other

23
01:03.920 --> 01:07.610
things such as the Python version running on the system, maybe we want to learn

24
01:07.610 --> 01:07.960
about

25
01:07.960 --> 01:12.360
the actual architecture of the device, all of this would be comprised within

26
01:12.360 --> 01:13.000
the facts

27
01:13.000 --> 01:15.640
retrieved from the managed devices.

28
01:15.640 --> 01:20.410
Now we're not just collecting random information for no reason, one of the best

29
01:20.410 --> 01:21.440
use cases for

30
01:21.440 --> 01:26.040
having this information is so that we can actually involve conditional logic.

31
01:26.040 --> 01:30.090
So maybe we want to perform a particular task based on the type of distribution
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

31
01:26.040 --> 01:30.090
So maybe we want to perform a particular task based on the type of distribution

32
01:30.090 --> 01:30.560
that we

33
01:30.560 --> 01:34.560
happen to be managing, but how do we actually determine the distribution?

34
01:34.560 --> 01:37.680
Well, we can get that via a fact collection.

35
01:37.680 --> 01:42.060
Similarly, what if we want to perform a particular task on the system, but only

36
01:42.060 --> 01:43.000
if it has enough

37
01:43.000 --> 01:45.360
RAM to support such a task?

38
01:45.360 --> 01:49.690
Well, we can easily pull facts about the devices that we happen to be managing,

39
01:49.690 --> 01:50.120
determine

40
01:50.120 --> 01:54.710
the amount of RAM on that particular system, and depending on the result, we

41
01:54.710 --> 01:55.440
can utilize

42
01:55.440 --> 01:59.870
the when keyword to invoke that conditional logic and apply the task as

43
01:59.870 --> 02:00.760
required.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
01:59.870 --> 02:00.760
required.

44
02:00.760 --> 02:03.740
Now one thing to state is that by default, and suppose it's going to

45
02:03.740 --> 02:05.080
automatically collect

46
02:05.080 --> 02:06.080
these facts.

47
02:06.080 --> 02:10.680
However, just because it is a default behavior does not mean that we have to

48
02:10.680 --> 02:11.480
always do it,

49
02:11.480 --> 02:13.720
we do have the ability to control this.

50
02:13.720 --> 02:18.840
Indeed, if we so wish, we can set the gather facts option to the billion value

51
02:18.840 --> 02:19.640
of false,

52
02:19.640 --> 02:22.880
and that is going to negate the collection of the facts.

53
02:22.880 --> 02:26.990
Now you might be wondering why on earth would be ever want to not collect facts

54
02:26.990 --> 02:27.640
, as it does

55
02:27.640 --> 02:29.160
seem to be pretty useful.

56
02:29.160 --> 02:33.660
Well the reality is when we do collect facts, it does take a little bit of time
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
02:29.160 --> 02:33.660
Well the reality is when we do collect facts, it does take a little bit of time

57
02:33.660 --> 02:34.600
, especially

58
02:34.600 --> 02:36.840
when you're managing many, many devices.

59
02:36.840 --> 02:40.520
So as such, if you don't really require the use of facts in a particular

60
02:40.520 --> 02:41.280
playbook, you

61
02:41.280 --> 02:45.360
can set this value and really effectively speed up the process.

62
02:45.360 --> 02:49.730
So it is important to state that we do have the option also to still leverage

63
02:49.730 --> 02:50.240
the use

64
02:50.240 --> 02:55.260
of facts without having to gather them explicitly via the use of a fact caching

65
02:55.260 --> 02:56.280
mechanism.

66
02:56.280 --> 02:59.630
So this is an option that will give the control mode information about the

67
02:59.630 --> 03:00.480
managed devices
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

67
02:59.630 --> 03:00.480
managed devices

68
03:00.480 --> 03:04.910
just be aware though, as if you happen to invoke fact caching, the information

69
03:04.910 --> 03:05.320
might

70
03:05.320 --> 03:07.320
not be exactly correct.

71
03:07.320 --> 03:10.520
After all things do change, things do become outdated.

72
03:10.520 --> 03:14.370
If you're lying on the cash, understand if we do indeed choose the cash, the

73
03:14.370 --> 03:15.120
information

74
03:15.120 --> 03:16.800
might be outdated.

75
03:16.800 --> 03:20.460
Now as always, one of the best ways to understand the particular concept within

76
03:20.460 --> 03:21.000
Ansible is

77
03:21.000 --> 03:23.200
to go directly to the documentation.

78
03:23.200 --> 03:25.440
So with that said, let's just do that.

79
03:25.440 --> 03:29.280
So if you happen to search for Ansible Facts, let's click this top link right

80
03:29.280 --> 03:29.720
here.

81
03:29.720 --> 03:33.240
And if we just scroll on down, what it says here is that with Ansible you can
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

81
03:29.720 --> 03:33.240
And if we just scroll on down, what it says here is that with Ansible you can

82
03:33.240 --> 03:33.960
effectively

83
03:33.960 --> 03:37.590
pull information about your system that you happen to be managing, and the

84
03:37.590 --> 03:38.600
variables related

85
03:38.600 --> 03:41.400
to the remote systems are called facts.

86
03:41.400 --> 03:44.630
So again, if you click this link here, as we can see here are Ansible Facts

87
03:44.630 --> 03:45.440
include things

88
03:45.440 --> 03:49.710
such as the operating system of the device that you're managing, as well as IP

89
03:49.710 --> 03:50.480
addresses,

90
03:50.480 --> 03:53.960
the attached file systems and even more information.

91
03:53.960 --> 03:57.980
Now one thing just to highlight right here, do you see this keyboard right here

92
03:57.980 --> 03:58.640
, Ansible

93
03:58.640 --> 03:59.960
underscore facts?

94
03:59.960 --> 04:02.720
This is actually a well known Ansible convention.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

94
03:59.960 --> 04:02.720
This is actually a well known Ansible convention.

95
04:02.720 --> 04:06.490
This is how we can actually see the information about the facts that we have

96
04:06.490 --> 04:07.280
gathered.

97
04:07.280 --> 04:10.520
So be aware, this is not just some random name that you can just change.

98
04:10.520 --> 04:13.080
This is built into the Ansible ecosystem.

99
04:13.080 --> 04:16.750
So how about we go and discover some of these basic facts about the systems

100
04:16.750 --> 04:17.480
that happen

101
04:17.480 --> 04:18.480
to be managing then?

102
04:18.480 --> 04:21.400
Okay, so here I am on my Ansible control node.

103
04:21.400 --> 04:23.960
What I will do is I'll write a simple playbook here.

104
04:23.960 --> 04:27.000
So I'll just call this, let's just say play one dot YML.

105
04:27.000 --> 04:29.560
So we'll get into insert mode, we'll have our three hyphens at the top to

106
04:29.560 --> 04:30.040
denote our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
04:29.560 --> 04:30.040
denote our

107
04:30.040 --> 04:31.040
yaml file.

108
04:31.040 --> 04:35.640
And I'll just say name, and I'll just say playbook to test fact gathering.

109
04:35.640 --> 04:38.080
So the host I'm going to target is going to be the all group.

110
04:38.080 --> 04:41.970
And like I say, by default Ansible is going to automatically collect these

111
04:41.970 --> 04:42.560
facts.

112
04:42.560 --> 04:46.340
So all I will do is I will specify my tasks here, and I'll try not to match the

113
04:46.340 --> 04:47.120
keypad.

114
04:47.120 --> 04:48.120
Let's go with that.

115
04:48.120 --> 04:51.400
And the name of this task will just simply be printing out the facts.

116
04:51.400 --> 04:55.610
Now all I will do here is use the debug module, and I'll use the message

117
04:55.610 --> 04:56.560
parameter.

118
04:56.560 --> 04:59.880
And all I'm going to print out are the actual facts I collect.

119
04:59.880 --> 05:02.750
And like I say, we have a very special convention that is going to be Ansible
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
04:59.880 --> 05:02.750
And like I say, we have a very special convention that is going to be Ansible

120
05:02.750 --> 05:03.800
underscore facts.

121
05:03.800 --> 05:08.800
So if I just press escape colon wq to write and quit, let's clear the screen.

122
05:08.800 --> 05:13.240
And I will just say Ansible playbook play one dot YML and hit enter.

123
05:13.240 --> 05:15.890
And right now we're going to be gathering facts about the systems that we

124
05:15.890 --> 05:16.320
happen to

125
05:16.320 --> 05:20.120
be managing that as the yellow box and the blue box within our inventory.

126
05:20.120 --> 05:23.480
And as we can see here, that was not what we expected.

127
05:23.480 --> 05:27.360
All that we have done here is print out the message Ansible underscore facts.

128
05:27.360 --> 05:30.920
The reason is because if we go back into the playbook, because I have used the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

128
05:27.360 --> 05:30.920
The reason is because if we go back into the playbook, because I have used the

129
05:30.920 --> 05:31.400
message

130
05:31.400 --> 05:35.310
parameter, what I'm going to have to do is to explicitly use my variable

131
05:35.310 --> 05:36.240
interpolation.

132
05:36.240 --> 05:39.200
So what I will do here is have my quotation marks.

133
05:39.200 --> 05:41.920
And I'm going to use my double curly braces here.

134
05:41.920 --> 05:42.920
Okay.

135
05:42.920 --> 05:44.680
So that will now be read as an actual variable.

136
05:44.680 --> 05:49.300
If I clear the screen and hit enter again, we run the playbook and this is

137
05:49.300 --> 05:50.040
looking a

138
05:50.040 --> 05:51.040
good bit healthier.

139
05:51.040 --> 05:54.160
So let's just scroll on up now as we scroll on up, you're going to notice we

140
05:54.160 --> 05:54.520
have an

141
05:54.520 --> 05:57.200
absolute ton of information here.

142
05:57.200 --> 06:00.600
We can see things about the kernel, the kernel version, the host name.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

142
05:57.200 --> 06:00.600
We can see things about the kernel, the kernel version, the host name.

143
06:00.600 --> 06:05.200
We can see MAC address information, IPV six, IPV four, that type of thing.

144
06:05.200 --> 06:08.920
But if we scroll on up to the very top, check this out right here.

145
06:08.920 --> 06:11.800
We actually have what are these key value pairs.

146
06:11.800 --> 06:17.080
Notice we have a key saying all IPV four addresses or all IPV six addresses.

147
06:17.080 --> 06:21.200
If we just want to access a very particular piece of information, we can do

148
06:21.200 --> 06:22.240
that specifying

149
06:22.240 --> 06:23.240
dot notation.

150
06:23.240 --> 06:27.040
So let's just grab, say for example, the all IPV four addresses key.

151
06:27.040 --> 06:30.040
Okay, let's just copy this and we'll go back into the playbook.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

151
06:27.040 --> 06:30.040
Okay, let's just copy this and we'll go back into the playbook.

152
06:30.040 --> 06:34.410
And what I will do here is I will just say answer my facts dot and then specify

153
06:34.410 --> 06:34.760
the key

154
06:34.760 --> 06:36.160
that I want to parse out.

155
06:36.160 --> 06:39.280
Okay, so we're going to parse in all IPV four addresses.

156
06:39.280 --> 06:40.600
Let's just write and quit.

157
06:40.600 --> 06:44.500
If I clear the screen and rerun the playbook, once again, we gather the facts

158
06:44.500 --> 06:45.200
and this time

159
06:45.200 --> 06:49.480
we're going to parse out just IPV four addressing on both of our devices.

160
06:49.480 --> 06:50.480
Check this out right here.

161
06:50.480 --> 06:53.790
The blue box we have the IPV four address of one nine two one six eight one six

162
06:53.790 --> 06:54.160
eight

163
06:54.160 --> 06:59.020
dot one three four and on the yellow box, the other device, we have the address

164
06:59.020 --> 06:59.400
one nine

165
06:59.400 --> 07:01.920
two one six eight one six eight one six eight one three five.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

165
06:59.400 --> 07:01.920
two one six eight one six eight one six eight one three five.

166
07:01.920 --> 07:04.720
This is indeed accurate information.

167
07:04.720 --> 07:08.270
Now if you wanted to parse out other information, then of course we could just

168
07:08.270 --> 07:09.280
parse out different

169
07:09.280 --> 07:10.680
keys within the output.

170
07:10.680 --> 07:15.100
Say for example, I want to perform an action on systems with 64 bit

171
07:15.100 --> 07:16.320
architecture.

172
07:16.320 --> 07:18.320
What I could do is pull out the answer.

173
07:18.320 --> 07:22.360
Well, thanks from the machine and parse out the architecture key and then

174
07:22.360 --> 07:23.160
compare it to

175
07:23.160 --> 07:25.000
the actual expected value.

176
07:25.000 --> 07:26.000
So let's just do that then.

177
07:26.000 --> 07:28.760
So let's just create one called play two dot YML again.

178
07:28.760 --> 07:30.240
We have our three hyphens.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

178
07:28.760 --> 07:30.240
We have our three hyphens.

179
07:30.240 --> 07:32.320
Just a test condition based on facts.

180
07:32.320 --> 07:33.560
Who am I going to target?

181
07:33.560 --> 07:37.680
I'm going to target the all group and let's define my task or just say checking

182
07:37.680 --> 07:38.800
architecture.

183
07:38.800 --> 07:41.620
Now in this case here, I'm just going to use a debug module with the message

184
07:41.620 --> 07:42.280
parameter.

185
07:42.280 --> 07:46.080
I'll just say this is a 64 bit machine.

186
07:46.080 --> 07:50.700
Now I only want to print this out when my answerable architecture returns a

187
07:50.700 --> 07:51.800
very particular

188
07:51.800 --> 07:52.800
value.

189
07:52.800 --> 07:56.140
So I'm going to say when and I'm going to grab my answerable facts and then I

190
07:56.140 --> 07:56.880
'll grab the

191
07:56.880 --> 08:01.460
architecture key and I'll make sure that is equal to the value of and as we saw
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

191
07:56.880 --> 08:01.460
architecture key and I'll make sure that is equal to the value of and as we saw

192
08:01.460 --> 08:01.760
, we're

193
08:01.760 --> 08:04.000
going to be going with arch 64.

194
08:04.000 --> 08:08.630
And now this particular action, this message is only going to work against the

195
08:08.630 --> 08:09.280
machines

196
08:09.280 --> 08:11.040
with this particular architecture.

197
08:11.040 --> 08:15.240
Now, of course, printing this message out is a rather trivial example.

198
08:15.240 --> 08:18.130
We could be installing particular software that requires this particular

199
08:18.130 --> 08:18.800
architecture,

200
08:18.800 --> 08:20.040
that type of thing.

201
08:20.040 --> 08:23.680
Right now, all we're doing is just demonstrating basic conditional logic with

202
08:23.680 --> 08:24.520
the utilization

203
08:24.520 --> 08:25.520
over fact collection.

204
08:25.520 --> 08:29.240
So let's just write in quits and let's run the second playbook.

205
08:29.240 --> 08:32.730
And as we can see, based on the result of our condition, both of our machines
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

205
08:29.240 --> 08:32.730
And as we can see, based on the result of our condition, both of our machines

206
08:32.730 --> 08:33.160
indeed

207
08:33.160 --> 08:35.200
do have a 64 bit architecture.

208
08:35.200 --> 08:38.250
Now, one thing to state is that when we happen to be running these playbooks,

209
08:38.250 --> 08:38.960
like a saber

210
08:38.960 --> 08:43.440
going to automatically be collecting those facts, if I wanted to turn off that

211
08:43.440 --> 08:44.240
behavior,

212
08:44.240 --> 08:49.720
what I could do is just simply specify right here, gather underscore facts and

213
08:49.720 --> 08:50.000
say that

214
08:50.000 --> 08:53.960
to the value of false, when I do this, we actually will not generate any answer

215
08:53.960 --> 08:54.640
able facts and

216
08:54.640 --> 08:58.240
what will happen is that the playbook is going to run a lot quicker.

217
08:58.240 --> 09:02.710
But of course, without the gathering of facts, this particular logic here is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

217
08:58.240 --> 09:02.710
But of course, without the gathering of facts, this particular logic here is

218
09:02.710 --> 09:03.520
not going to

219
09:03.520 --> 09:04.520
work.

220
09:04.520 --> 09:07.270
But nevertheless, if you're on the playbook and to answer, as we can see here,

221
09:07.270 --> 09:08.000
the conditional

222
09:08.000 --> 09:12.220
check has actually failed purely because as we can see here, we have no longer

223
09:12.220 --> 09:12.840
gathered

224
09:12.840 --> 09:13.720
error facts.