So friends, now that we know how to create archives,
as well as how we can unarchive our files,
let's add some more attention to how we can handle errors
in our Ansible Playbooks.
So you may notice that when you happen
to create a particular task in Ansible
and you encounter an error,
what effectively happens is the playbook just crashes.
So what this actually means is that
if you happen to have a whole bunch of tasks,
let's maybe say task one and task two
and perhaps even task three,
let's suppose we happen to have an error
in task one, maybe you try to copy a file to a destination WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in task one, maybe you try to copy a file to a destination
and that file doesn't even exist.
So the module fails and effectively the playbook crashes.
What this effectively means is that these two tasks,
even though they can be correctly configured,
well, they're not even going to get the chance
to be configured because basically Ansible
is going to work any sequential manner.
And as soon as we encounter this error here,
the playbook is just going to stop.
So what we want to be able to do is to learn
how we can handle our errors.
So that if we happen to encounter an error,
let's maybe say again on task one, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
let's maybe say again on task one,
the playbook acknowledges that error
and it handles it appropriately
and then continues on, meaning that task two and task three,
if they are correctly configured,
they can still actually execute.
Now, just as a quick note,
if you happen to have experience
with the Python programming language,
not that you have to note to use Ansible,
but many people who are using Ansible
do have familiarity.
What we're going to talk about here is quite similar
to what is known as a try and accept block.
Now, for those of you that do not have any experience,
with Python, let me talk to you about WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with Python, let me talk to you about
what we're actually talking about here.
In the case of Python,
when you want to try a piece of code
and hope that it works,
you can effectively use the try keyword
and any code within this statement
is going to be attempted to be ran.
However, if you happen to encounter an error,
you can create what is known as an accept block
and then specify what you want to happen
if the try block happens to fail.
So whilst in Python,
you would use the try keyword in Ansible,
we actually specify the block keyword
and with respect to the accept block WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and with respect to the accept block
that you would specify in Python,
what you actually say in Ansible as the keyword rescue.
So those of you with Python experience
probably now understand these concepts already,
but for those of you that don't,
let's dive into an example and see how it actually operates.
So let's go on and create a playbook called play3.yml.
So we're going to insert more TAVR3 hyphens at the top,
give it a name,
and we just say play3 handling errors
and try to spell that correctly, John.
There we go.
So let's now target the host. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's now target the host.
Let's just go with the blue box once again.
We'll set gather facts to be false.
And now let's define our tasks.
So the first task here,
let's imagine we want to copy a particular file here.
So we'll use the Ansible built-in copy module
and I will specify as the source is going to be,
so let's go into my home Ansible directory
and let's just specify a file called random.txt.
And then specify we want to copy it
into the nugget user directory
and the file can also be called random.txt.
Now the problem is going to be here
that on my control mode, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that on my control mode,
this file here does not actually exist.
Let me show you that, okay?
So we can see the directory I'm into an LS.
Notice we actually don't see this random.txt file.
So we're going to encounter an error.
So let's continue on and have more tasks.
Let's just call this do something else.
Now this can be absolutely anything.
This could be perhaps copying more files.
It could be creating new directories.
It could be compressing files, all that stuff.
It doesn't actually matter.
In the case here, just for the example,
let me just print out a simple message, okay?
So I'll use the Ansible built-in debug module
and the message is going to be, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and the message is going to be,
this is the second task, okay?
Super, super simple.
Now as it transpires right now, like I say,
because we're going to have a failure
and this particular task here,
the playbook is going to crash
and therefore this task here will not actually execute.
So let's just save this
and I'll just say Ansible,
play book, play three dot YML and to enter
and look at this right here.
We just get an exception, pretty much an error,
specifying that we could not actually find or access WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
specifying that we could not actually find or access
this particular text file on the Ansible controller.
So this is the error.
Notice though, crucially, where is the second task?
It didn't actually execute.
We don't get to see that printed message.
So here's what we can do.
I think we'll go back into the actual playbook here.
So let's go in and say play three dot YML.
What I'm going to do here is I'm going to create a block
and I'm going to effectively indent everything
so let me just give this a new name.
So let's say attempt to copy the file
and let me just fix my indentation.
So let's move this in for spaces and again,
for spaces again. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for spaces again.
And let's maybe just change this name to do multiple tasks
to be a little bit more descriptive.
Now at the same level of indentation as our block,
we want to use the rescue keyboard.
So I'll say rescue and now I'll give this a name
and I'll just say handle the error.
Now again, the way you handle this is entirely up to you.
You can perhaps maybe create a log file of the error.
In the case here,
what is used the answer will build in debug module
to simply print out a message.
What is that message going to be?
Just say the copy task failed.
Now with respect to the next task,
effectively our simulation task that is not really doing much. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
effectively our simulation task that is not really doing much.
I want this to always execute regardless, okay?
So at the same level of indentation
as the block and rescue keywords,
let me have the always keyword
and now just indent everything within once again.
So again, for spaces, indent it.
Perfect.
So now we have this new playbook.
So whilst this file here does not exist,
we're going to encounter an error,
as opposed to crashing,
we'll specify that we want to print this particular message
and then we will continue on with the other tasks
that you want to execute.
So let's go for this here.
I'll say answer will playbook, play through.yml WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'll say answer will playbook, play through.yml
and to answer, look at this right here.
We actually get an error message as we saw before,
but this time we continue on,
we specify that hey, the copy task happened to fail
and now the next task here is going to execute.
Now again, the example is a little bit frivolous here,
but you can imagine this could be any particular task
no matter how advanced.