Instructor: So now let's discuss how we can continue
to roll back on updates.
So whenever a rollback happens, maybe sometimes
the rollback itself will be a failure
and you will be in a state named UPDATES_ROLLBACK_FAILED.
In that case, the resource can not return
to its original state, causing the rollback to fail.
For example, you roll back
an old database instance, but it was deleted
outside of CloudFormation.
So for example, we create a stack,
The create is complete,
and the RDS database instance is created
as part of my stack.
Then we update the stack,
which is going to create a new RDS database instance,
but the update rollback will fail
because the new instance will have a failure as well.
And it turns out that in the meantime
our user has deleted our previous RDS database.
And so therefore this is a very, very edge case, right?
But this will trigger an update rollback fails.
So the solution, when you have this,
is to fix the error manually outside of CloudFormation,
and then continue to do the rollback of the stack.
Or we can skip the resources that can not
be rolled back successfully.
And then the CloudFormation will automatically
mark the failed resources as UPDATES_COMPLETE.
And, if you are in the UPDATES_ROLLBACK_FAILED state,
this is the only two things you can do.
You can not update the stack in this state
so you cannot apply an update on top of it.
And in case of nested stacks, then rolling back
the parents cycle will attempt to roll back all
the child stacks as well.
So that's it.
Now let's go into the hands-on to practice this.
Okay. So let's see
how we can trigger an UPDATE_ROLLBACK_FAILED.
So we're going to have a rollback
and first we need to create a stack.
So we're going to specify an image ID,
which for Amazon, there's two,
and we're going to create an AutoScalingGroup, okay?
And we will find an AvailabilityZone to use it.
So we'll use the first one from the AZs within the region.
So this is a cool way to see a new function called GetAZs.
And this is to find all the availability zones
within a region.
And then we can do Select, just like the first one.
We have a DesiredCapacity of one,
MaxSize of one, and MinSize of one.
And the LaunchConfigurationName
is referencing this LaunchConfiguration right here.
Now this LaunchConfiguration is very, very simple.
We have an ImageId,
which represents the ImageId that we have from above,
from the parameter, and InstanceType is t2.micro.
So effectively, we create an ASG with one InstituteInstance
and it's being a t2.micro.
So let's upload these templates,
and I'm going to go into ContinuedRollback
and choose the first one.
So DemoRollback, and next,
next,
and then create this stack.
So my ASG is now created.
If I go to resources I can find my launch configuration,
as well as my auto-scaling group.
Okay.
So here's my auto-scaling group.
And, as we can see here, we have one instance.
There's our capacity of one,
and under Instance Managements,
we will find our instance right here.
Okay. So this is excellent.
And under Launch configuration,
as we can see the Launch configuration is right here,
and it is created.
So now we want to trigger an update
and a failure on the updates,
which will trigger a rollback.
So a lot to do.
But let's go and open continue-rollback-failed.yaml.
So the parameter here is the same for the ImageId.
The ASG has the exact same configuration,
so we don't change anything here,
but what we're going to change is the LaunchConfiguration.
So the LaunchConfiguration
now has an InstanceType of t2.nano.
Effectively, this will create a new LaunchConfiguration
within the CloudFormation, okay?
So we have this one,
this one is going to be created.
And then we also have a WaitCondition,
and the WaitCondition
is a way for the confirmation template to wait
for a signal coming from the CFN signal commands, okay?
And this WaitCondition is having a CreationPolicy
of resource signal, Count equals one,
and the Timeout of one minute.
So what will happen
is that this WaitCondition will never receive a signal
because nothing in its templates will send a signal to it.
And therefore, because the WaitCondition will have an error,
it will go into a ROLLBACK state.
But, let's add something and say that, unfortunately,
an employee wanted to create a new Launch configuration.
So went ahead and say NewLaunchConfig, okay?
The AMI is going to be manually done,
so I will choose Amazon and Linux two.
So Amazon and Linux two...
Let's just find the AMI from right here.
So here's my AMI ID,
and I'm going to just do something manual.
So this is an employee that does something really bad.
So a NewLC, here is the AMI that I'm going to put in.
Perfect. The instance type is going to be a t2.micro,
so I have to click and choose instance type.
And I will, again, use a t2.micro.
This is going to be the same kind of Launch configuration,
but a different physical one within AWS.
So everything else looks good,
and I'm going to create a new security group,
it doesn't really matter, and choose a key pair.
Here we go, I acknowledge,
and create this Launch configuration.
Okay? So now we're going to go ahead
and update our Auto Scaling group.
So we'll edit our Auto Scaling group
and the Launch configuration.
Now what I'm going to use is the NewLC.
So we go ahead and we're good.
You updates, and the updates is successful.
And now I'm a really, really bad employee.
So I'm going to take this one
this old launch configuration, and I'm going to delete it.
So this is one that was managed by cloud formation.
So as we can see now we've updated the launch configuration
of our ESG and we've replaced it with a new one.
And the old one from cloud formation is gone.
So all of this is a good recipe to trigger
the behavior we want.
So we're going to update this
and I will replace the current templates by
continue roll back failed.
So this should create another launch configuration.
Okay? But this time we will not receive a signal
on the Wade condition.
It will go into a rollback, but the world bank will fail
because the previous launch configuration that was created
by cloud formation does not exist anymore.
So let's go ahead and look at the chain set.
So the LC is going to be modified
and there's going to be a replacement true.
So this is going to create a new launch
configuration and the ESG will also be modified as well.
And the wait condition has been added.
So let's update the stack
and now the updates is in progress.
The new launch configuration has been created.
So if you go into here and refresh
we can find a new launch figuration right here
of type of t2.nano.
And as long
as configuration is going to be applied to my ESG.
So this is complete.
My ESG does have access to the new launch configuration
and now we have a wait condition.
So this wait condition remember is going to be waiting
for a signal and the signal, it wants one signal
and with a timeout of one minutes, but this will not happen
because we are not sending any signal
to our cloud formation stack.
And so therefore this will trigger a rollback.
So as we can see now
the wait condition failed to receive one resource signal.
So the rollback was in progress.
The LC got updated there.
So the Os was deleted
and then the ASG was supposed to be updated.
But now it is saying, Hey, this lunch configuration
with this name demo rolled by blah, blah blah,
does not exist anymore, which is not expected.
And so therefore the ASG has been failed to be rolled back
which is a problem, obviously.
So we need to fix this.
And so for stack actions
we can click on continue update, roll back.
And so we have two options either.
We want to skip this resource, the ASG
and we're saying, Hey, it's okay.
This ASG, we'll just give the rollback.
And we're happy with the state it's in.
Or we can just continue update roll back and try again.
Okay. Now this is the only way for you to do it.
You can not update the stack right now.
So to solve this problem.
Well we have to recreate this launch configuration
manually to fix our problems.
So let's create a launch configuration.
Here is the name.
The AMi is going to be the one from before.
So let me get it.
It's not very easy to always get it
but let's go to launch configurations find it here.
And here's my AMI.
Great. The instance type is going to be a t2.micro.
Great I will choose that.
And I will go ahead
and just create my launch configuration.
I can choose a keyPair.
It doesn't really matter that we'll have a drift.
We can actually see the drift as well.
It'd be pretty interesting.
So now my demo roll back with the right name is recreated.
And so I can, again, stack action
continue update roll back, and continue update rollback.
So this is going to try again, to do the rollback
and update my ASG.
But now because well, the ASG found
the previous launch configuration it was successful.
And therefore we went into a delete_complete for the old
for the new logical configuration.
And the update rollback is complete
for my stack, which is cool.
And as a bonus
we can detect the drift to see if anything has been drifting
from our initial configuration.
So we can look at the drift results
and we can see that for now, everything is in sync.
So I guess it did not detect anything special
regarding two security groups, but that's okay.
This is the limits of drift.
It's the best effort I think, in the end.
So cool.
That's it for this demo.
I hope you liked it and don't forget to delete
to your ASG and it we'll see you in the next lecture.