So throughout this skill, what we've been effectively doing is testing
different parts of our system,
testing the memory, testing the CPU, that type of thing, as well as learning
how to manipulate particular values.
Now, what we can do also is to utilize a very particular Ansible module,
which is really designed for testing purposes, and that is the assert module.
So how about we go to the documentation and have a look at what this module
actually does.
So if you just happen to search for Ansible Assert and collect this top link WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if you just happen to search for Ansible Assert and collect this top link
right here,
as you can see straight away, this module is part of Ansible Core,
so you don't actually have to install it via Ansible Galaxy.
And if you want to use it, you can specify the fully qualified collection name
of Ansible.builtin.assert.
Now if we just scroll on down a little bit here, we can see the synopsis.
It says here that its whole purpose is to assert that given expressions are
true with an optional custom message.
So really, this is what we've been doing with respect to our test.
We're testing it as something true or as something false, as this particular WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're testing it as something true or as something false, as this particular
number over this particular value,
is that true or as that false, and then have a message.
And this particular module we have this nice elegant way to specify within the
same task,
if a test happens to fail or if a test happens to pass.
So if we scroll on down here, we can see we happen to have a parameter fail_msg
.
This is how we specify the custom message that we want to use when a failure
happens.
Conversely, if we scroll on down, we also have this other option,
success_msg. This is the custom message that you specify when you have a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
success_msg. This is the custom message that you specify when you have a
successful assertion i.e. when the test pass.
Then if we scroll on down, we also have the that keyword.
And as we can see here, this one is actually required.
So the module cannot work unless you use this particular parameter.
So realistically, if we scroll on down, we can see all of these additional
examples right here.
And feel free to copy them, paste them, try them out and see how you get on.
But from now, let's write one of our own, which is really quite simple.
So let's go back and we'll create a playbook called Play4.yml WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's go back and we'll create a playbook called Play4.yml
and go into Incent Mode, have our three hyphens at the top, give the playbook a
name,
and I'll just say Play4, testing the asset module.
So the host I'm going to target will be the all group, and again, we'll set
gather_facts to false.
We still don't need these facts.
And then we will specify our task.
Now the very first task is going to have a name.
And let's just say, test whether a file exists.
Now if you recall earlier on within this course, we happen to use the stat
module.
Again, this is built in, we don't have to install anything. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Again, this is built in, we don't have to install anything.
And pretty much, this is going to allow us to determine whether a file exists,
as well as a whole bunch of other information, such as as the file directory,
what is the size of the file that type of thing.
So we can use this to perform a very simple test.
Let's go back to our playbook then.
And the module we will use will be Ansible.bilton.stat.
Now in this case here, we're going to supply a particular path.
So what I will do here is I'll go into my blue box.
So let's go into the 10th directory, do an LS.
If I just create a little file here, let's call this, or I don't know. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If I just create a little file here, let's call this, or I don't know.
Let's just say recipe.txt, go into insert mode, and we just add in some values,
check in potatoes and veg.
And crucially, we won't have this particular file over on the yellow box.
So let's use Ansible to detect the presence of that file across our devices.
So what I will do here is specify the path that I want to check.
I will say forward slash TMP, and then it's going to be recipe.
And I want to capture the output as a variables, let's just call this, recipe
output.
And now I'll have a new task with the name just specifying a set, whether the
recipe file exists. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
recipe file exists.
So to specify the Ansible built in a set module right here.
Now remember, the required parameter is the keyword that.
And now I want to grab my variable here.
And because I have used the STAT module, if your recall, this is going to bind
some
particular attributes to the actual variable itself.
So we can go into the STAT attribute and then we should also have an attribute
known as
exists.
And now here very elegantly, we can specify our success message.
And thank rotation marks, I'll just say the recipe.txt file exists on. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And thank rotation marks, I'll just say the recipe.txt file exists on.
And I'll specify my inventory host name.
And I'll also have my failure message.
So specify fail underscore MSG.
And with the rotation marks, I'll say the recipe.txt file does not exist.
And again, I'll pass in my inventory host name.
So fairly simple test.
And it is very readable.
So if I go back to my terminal run my playbook of playbook 4.YML,
we should see a result specifying that the blue box does have this fail,
whereas the yellow box does not. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
whereas the yellow box does not.
So let's try and hit enter.
And the playbook runs now.
Look at the output here.
This is really, really handy.
We get to see our message.
And the case of the blue box here, it specifies the recipe.txt file exists in
the blue box.
But more interestingly, is that when we happen to have a failure,
we then just print out a fail message.
We actually instructed Ansible about a genuine failure.
Look at this.
Ansible reporting a failure.
And in our play recap, we can actually see we've updated a failure right here.
You see that one failure is present.
This is also one of the advantages of using this particular module. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is also one of the advantages of using this particular module.
As opposed to you just printing out a message saying, hey, the test field,
and effectively it's not really updated in the Ansible output here.
So by using the assert module, we get that update,
and we get this nice clean way to specify whether a test passed,
or whether in this case here a test happened to fail.
So with all that said, let's now validate what we've learned within this scale.