OK, so now let's go back in to our auto scaling group.
So say this is great, this is looking good, and these have been launched using this launch configuration
right here and say we want to update that Otis counting group.
Right.
So why don't we go ahead and have a try at it.
So have created this one.
One is of the policy.
And so we can see this is the exact same template as before.
OK.
This is the exact same thing from which is going group.
But the launch configuration is a little bit different.
I've updated the launch configuration such as now.
It says Hello World before doing the updates and then doing the signal.
So I'm going to try to update my auto scanning group with this and see what happens.
So if I go into cloud formation and I click on updates, I'm going to replace the current templates
and I'm going to upload a file and I'll choose the first one.
And I'm going to click on Next, next, next.
And so what this will do is that this will create a new launch configuration.
It's verify that.
So, yes, there's a new launch configuration and my oh, just cutting group is going to be modified
to have that launch configuration as well.
So I'll click on Update Stack and the update is not in progress.
So then you wait for it to happen.
And now the update is complete.
So let's get back into our discussion group and link to refresh this page.
So, yes, this LONGE configuration has been updated to start with one J.
Nine G.
OK.
And if I go to my instances and then look at them, while these instances are not using the latest launch
configuration.
So somehow these instances have not been updated.
My oldest coding group itself has been updated using this launch configuration, but my instances in
this discussion group have not been updated.
And as such, one may wonder, well, how can I make sure that my just getting group does update my
instances whenever I change my lunch configurations?
Good.
That may be something you desire.
And for this, we're going to use the updates, policy attributes.
And so the update policy is applied to just getting group Alanda Alias or Elastic Case Replication Group.
But for this lecture, we'll just consider the auto getting group.
And so we'll specify an update policy.
And with this update policy, we can specify three things.
We can specify whether what we want replacing updates.
So Lotos killing, replacing updates and auto scaling, rolling updates or.
And finally, some alea, some attribute called auto scaling.
Schedule action.
So you need to remember this going through the exam.
There are three things you can specify for your update policy replacing updates, rolling updates and
the auto scaling schedule actions.
So let's go and have a deep dive into one of those to get started.
So we'll first look at the rolling one.
So we've look at these templates.
This is same as before.
The printers is the same.
The other scanning group is the same, except that now we have added a update policy to it.
And this update policy is specifying an auto scaling rolling update.
So this ruling updates a saying that's the minimum instances and service must be one.
And the max batch size to update this auto scanning group is two.
So because we have three instances, that means that two will be taken down for rolling out, that one
will be in service and maximum two at a time.
So this is how fast we want this update to happen.
Then we specify a pastime time, which is how much buzz we want to give for the new instances to come
up and give us a signal.
So one minutes and if we don't receive a signal in one minute, then we have to roll back.
And do we want to wait on resource signals?
True.
Yes.
We want to wait for a signal for this update policy.
And additionally, we set up a Lotos killing schedule action to prevent the fact that schedule actions
should modify the min max and designed for Clapham for confirmation in the RSG.
So that means that, for example, if you have conflicting schedule actions while you're doing an update
and confirmation, this may lead to bad behavior.
So, two, to resolve against this, you justify this Bluck of auto scaling, schedule action and ignore
unmodified group size properties.
True.
But I think what's really matter is going into the exam is knowing that the auto scaling rolling update
exists.
And as its name indicates, it will do a rolling updates from within the same auto scaling group.
So why don't we test this one?
And by the way, the launch configuration, again, has changed.
We now say Helliwell two so that we trigger some kind of updates.
So let's go back into cloud formation.
I'm going to update this one and I'll replace the current templates Allapattah file.
And this well will be number two updates, rolling policy and so critical next.
Click on Next.
And then finally, click on Update Stack.
So this will create a new launch configuration again.
But this time it will.
It will update the launch configuration on our ASG.
It will also make sure that the instance isn't here gets replaced because of this update policy we have
specified.
So it's for it to happen.
Here we go.
We can look at it now.
So these just getting group.
Let me show you.
Here we go.
So the Lundstrom thing has been updated.
So we have a new one.
And here the OTA is going to be saying, OK, the rolling update has been initiated, will terminate
three obsolete instances in batches of two.
Well, keeping at least one instance in service.
And we'll wait on resource signals with a timeout of one minutes when the new instances are added to
the auto's getting group.
So this is quite a nice way to show us what we need to have based on the code that we have specified
rights here.
OK.
So now let's look at the next status.
It says, OK, temporarily setting the authors, getting group midsize.
And these are capacity two, three.
So it has changed that.
So if we refresh this, the midsize is now three.
And then we go again in here, sorry, in confirmation.
Then it says a gate terminating two instances and replacing with two new instances.
As you can see, it did two do a replace.
It did have to terminate instances first and then creating new instances.
I'll refresh test to see the signal.
So, OK.
Here we are.
Then it says successfully terminated instances.
So that's sixty seven percent progress for this rolling update.
Then the new instances are added to the auto scanning group and it's waiting for the two resource signals
with a timeout of peaty one minutes and has received one signal.
So it's partly going to receive a second one very, very soon.
Yeah, it has received the second one.
So now two instances have successfully been updated, so this one and this one are updated and is going
to do the last batch in my US things.
So it's going to terminate this instance and replace it with a new one.
So here we go.
A new one is pending already.
And so, again, if I refresh this, it has to me to the instance and it will wait for a success signal
from that instance.
And when that instance has given us a success signal, then everything will be working.
So let's wait for it to happen.
And now it says that the last instance was successfully terminated and it was winning one minutes to
receive a signal, a success signal.
And then he received the signal.
So it says, OK.
Update completes.
And we have just performed our first rolling upgrade of our auto scanning groups.
That's one way of doing things.
And you have to remember this going into your exam, you can perform a rolling updates.
OK, for you.
Also, Skellig using an update policy.
But the last thing I want to show you as part of this lecture is that you can have a replacement policy.
So instead of doing a rolling update, we're going to do a replacing updates.
Remember, this is a second kind of that you can do.
And we'll say we'll replace true and this replacing updates.
What it does is it will say, OK, create an entirely new auto scaling group.
And then when that is going to group has successfully passed the creation policy.
This one then terminates the old oh, just going group.
So let's try this out here.
We're going to create a new well, just getting groups.
So this is more than like an immutable type of updates.
So I'm going to update this, replace the current templates of the file and I will choose number three.
So this should create a new auto's going group altogether.
So let's have a look and see if that works.
I'm going to update my stack.
Here we go.
So now the update is in progress.
OK.
And there is a new resources to be needing to be created.
So the resource creation have been initiated.
And if you go back to the otoscope group UI and I refresh this now, we can see that we have a third
of those coming.
I mean, the second one as part of this disconfirmation template, a 30 my UI.
So this new auto's cutting group has been created and has the same settings as the other one annuals,
three instances.
But this one has the new launch configuration, while this one has the old launch configuration.
So now we're waiting for three instances to be started.
So they're pending states.
And because this is a new auto scaling group and we have three new instances, then again, the creation
policy we have specified will take place.
So if I refresh this, I should start talking about my creation policy, or maybe if it doesn't, at
least is taken into account.
Trust me.
So let me wait for everything to happen and let's see what the UI says us.
So here we go.
We have received one, two and three Cygnus success signal from these three instances that were created
in this new auto scanning group.
And now what will happen is that the update is incomplete.
And then there's a cleanup happening and is going to delete my old photos scaling group.
So if I refresh this and refresh this page right here, we can show that, yes, this old just coming
group right now is terminating all the instances.
And then when it has terminated all the instances, then we'll only have the new or just group in place.
And as such, we'll have performed a replace type of update, which is an immutable type of updates.
OK.
So this is really important to see and I think quite good to see the difference.
A bit policy.
So if you don't specify anything, it will just update the launch configuration but won't do anything
to instances.
If you specify a rolling update for your update policy.
Then that means that instances will be created and terminated within the same kind of group.
And if you specify a replace updates, it will create a new auto scanning group altogether and place
instances in them.
So finally, there's one documents they need to make sure to read is how can I make sure that my just
getting group is updated the right way during a confirmation stack updates.
And they describe a few issues that you can have and the resolution.
So I do encourage you to read that document because I think it's quite an interesting one.
Do you really understand how the update policy do work in the real world?
I don't think it's something you have to know by heart for the exam.
But if you read through these documents and understand it, that means that you have understood how
the update policy work.
And that means that my job is complete and that you'll be ready for the exam on that topic.
Okay.
So that's it for this lecture.
I will see you in the next lecture.