Narrator: Okay so as I said,
we still don't know how to tell CloudFormation
that the EC2 instance got properly configured.
That it was successful after doing a cfn-init.
Maybe it failed.
Maybe we don't want CloudFormation to complete because
our configuration of our instance has failed.
And so for this we can use the cfn-signal script.
And so for this we will run the cfn-signal command
right after the cfn-init command
and we will tell CloudFormation service
to keep on going or fail, based on that outcome.
For this, we'll need to define a WaitCondition.
And the WaitCondition
will tell the CloudFormation templates
to wait until it receives a signal
from cfn-signal.
So we'll block the templates
until it receives a signal
and we will attach a CreationPolicy.
Basically that also works on EC2 and ASG,
but the CreationPolicy will dictate
how many signals we want to receive
and for how long we're willing to wait.
No worries, we'll see the code in a second
so keep on hanging.
In terms of the diagram, for you to visualize how it works
we have the CloudFormation service
and it will launch an EC2 instance, just like before.
This time though, there will be a WaitCondition.
So the WaitCondition will just wait
and put the CloudFormation service in hang mode.
And it will wait until it receives a signal.
So in the meantime, the EC2 instance will run
the cfn-init script.
And so it will querie
the CloudFormation service to retrieve the init data,
just like it did before.
But then after it's done we will run the cfn-signal script
and we will signal the WaitCondition that we're done.
And then CloudFormation will be happy
and will be able to move ahead.
So let's go how this works in practice.
So in cfn-init.yaml as we can see we ran the cfn-init file,
but that was it, nothing afterwards.
So let's go to cfn-signal
and we'll look at this.
So the exact same parameters, the exact same EC2 instance
but now if you look at the UserData
after the cfn-init command
we're going to run the cfn-signal command.
And it's basically going through this little
minus e, dollar, question mark.
So this is special batch.
But it basically says, if this works,
then send a good signal.
If this didn't work, then send a bad signal.
And we're going to signal our stack.
And we're going to signal our WaitCondition,
so the simple WaitCondition
that was defined right here in the bottom,
I'll go over it in a second,
in this region.
And so this is saying,
if this works, signal the WaitCondition that it's all good.
If it didn't work, then still signal the WaitCondition
that it didn't work.
And then CloudFormation will draw its conclusion.
The Metadata itself hasn't changed.
It is exact same CloudFormation init.
So, because it worked before, it should work now too.
Okay let's scroll down.
And here is our WaitCondition.
So our WaitCondition, the type of it is a
CloudFormation WaitCondition.
And the creation policy says that
we're waiting for a resource signal.
And the time out is going to be--
and I'll just set it to two minutes, just to be fair.
So PT two minutes, that means
I'm waiting for a resource signal for two minutes
and when I receive it, I'll be happy.
You can also specify counts.
If you wanted to, you could say count two,
but that would make no sense
because we're not sending two signals.
That is if you create multiple EC2 instances.
For us it could be count one
because we're just waiting on one instance.
So I'll just leave it like this.
So the sample WaitCondition
is waiting for one instance to signal
something within two minutes.
And that signal should be obviously positive.
And we know that a signal has been sent to this
through the command right here.
It says resource sample WaitCondition.
The rest is the same.
The SSH security group has the same rules.
And so the only thing we've added in this stack really
is the WaitCondition
and the cfn-signal script, and our user data.
So let's have a look at how this works.
So we are in CloudFormation, I'll create a stack,
upload a template file,
and this time I will upload cfn-signal.yaml.
Click on next, and I want to say cfn-signal-example.
And I'll just remove the typo, because that's pretty bad.
Okay.
Now the SSH key is going to be the same as before.
Click on next, and on the bottom
click on create stack.
So now the cool thing though,
is that I will not pause the video
because I want to show you exactly how things happen
in real time.
So we're waiting for things to happen.
The SSH security group
is in create progress, and the sample WaitCondition
is in create progress too.
Now we're just waiting for our EC2 instance to set up.
So my instance
is now in create in progress
so if I go to my EC2 management console
I should be seeing my EC2 instance
that is starting right now.
But as you can see,
my WaitCondition is still in create in progress,
so it's still waiting.
So I'll refresh again
and wait for it to happen.
Okay so my EC2 instance is now running.
And so if I go back to CloudFormation,
this is usually when things would end.
It would say MyInstance, create complete.
So it's going to show this in a second.
Create complete, here we go.
MyInstance, create complete.
And so the stack is still not completed
because the sample WaitCondition is waiting.
So if you go back to stacks
you see it's still create in progress.
So it's because the WaitCondition is waiting for a signal.
And so this will not happen up until
the EC2 instance will have configured itself
and used the cfn-signal.
So I'm just going to wait again a little bit
for the cfn-signal to arrive, and here we go.
The sample WaitCondition has received a success signal
with this UniqueID.
And so that was about 20 seconds after
my EC2 instance has created.
And because I received a proper success signal
then we went into create complete stage.
And so that's the cool thing.
The WaitCondition had to wait
20 seconds for it to complete.
Now if I go to my EC2 management console
and open up my public IP
I will know for sure that it has worked
because the cfn-signal sent
a positive signal to CloudFormation.
And so that's the really cool thing.
Now with WaitCondition we are able
to basically say, wait a little bit
until you can get, say, okay your stack has worked
because the EC2 instance will be able
to send a signal right away.
In the next lecture, we'll see what happens when
things fail, because that's a very important
test case for the examination.
But that's it.
For now, we've just seen that a WaitCondition
allows us to wait til it completes
before we receive a signal.
As usual, I will go ahead and delete my stack
and I will see you in the next lecture.