In this demo, we're going to look at updates and rollbacks for deployments in Cuba.
So in the previous demo, we used a deployment definition file, which is located in the deployment
directory of our project folder.
The name of the deployment is my app deployment.
And we have updated the file to use six replicas all year.
It was three and it is using an index image.
So to create this deployment, we will use the Cube Cuttle Create Deployment Command.
But before that, let's quickly check and make sure that there are no objects created in the cluster.
OK.
That looks good.
So I'm going to run the cube to create command with the dash F option to specify the deployment of Yamal
has the file.
So once we run this command, the deployment is created.
Now, let's make use of a new command called the Cube Cuttle Rollout Status Command with the deployment
name to check the status of the deployment.
So as soon as I run this command, I see that the deployment, my app dash deployment has been successfully
rolled out.
Now, if we had run this command more quickly, like right after we ran the command to create the deployment,
we would have seen a different status.
So let's quickly delete this deployment.
And what I'm going to do now is I'm going to create the deployment again and I'm going to quickly run
the status command right after I do it.
As soon as I run this command, it will show you the status of each replica which is being brought up.
So remember that we have used six replicas in total.
And as soon as we are on the status command after deleting the deployment, we see that it tries to
bring out the pod one at a time.
So here we have zero out of six and then one out of six.
Two out of six, et cetera.
So until all the six pots are up and running, you'll see a status message related to that.
And only after all the parts have been deployed successfully will coordinators consider the deployment
to be successful.
So once deployed, we use another command to see the history of the deployment.
And for this, we will use the same command as before.
But instead of status, we will use the roll out.
History.
Command.
Now, you can see that the my AB deployment has one revision, which is the one that we just did, that
was creating the deployment itself.
And there is also a column called Change Costs, which you'll notice that has there is no change cost
specified.
And that is because we did not specifically ask it to record the cause of change while we created the
deployment.
So let's go back and fix that.
So we'll delete the deployment again.
Let's wait for the pod to be terminated.
So now it's in terminating state and let's wait for all of them to go away.
So now that all of them have been deleted, I'm going to run the same command as before.
But this time I'm going to use the dash dash record option.
The record option instructs Cabinet to record the cause of change, to execute that command now.
And again, I'll run the roll out status command to watch the status of deployment and wait for all
the parts to be up and for the deployment to be successful.
And now let's run the history comment again, and this time you'll see that against the revision.
There is a change course which is mentioned, which is essentially the same command that we ran to create
the deployment.
But because we use the dash dash record option, it is recording the command here.
So now let us try to make a change to the deployment.
So first, let's run the cubicle, describe a command with the name of the deployment.
And this pulls up the additional information and you'll see that in the annotations section, it has
recorded the command that we used to run this to create this deployment.
And we know that it is running six replicas.
And if you scroll down, you'll see that the image of this container, of this deployment is engine
X.
So let's make a change to that.
And for this, I'll make use of the cubicle edit deployment command.
And I'm also going to use the dash dash record option so that the cause of change is tracked in the
revision history.
So what I'm going to do now is I'm going to look up image.
And currently, it is set to end Genex.
So we will change this to a lower version.
And so this is using the latest version of Engine X currently.
And what we'll do is we will change it to another version, a lower version.
And for that, let's make use of the Docker hub documentation.
So here I am at Docker Hub and I'm looking at.
And Genex and you'll see that the current version, since we did not specify a target, is one dot one
nine.
As of this recording and let us make use of an older version, one out, one eight.
So back to the terminal.
I'm going to change the version to one dot one eight.
And for that, I'll add a colon and I'll mention the word number here.
And once I'm done with the changes, I'll use the WQ to save and exit the editor.
And now if you're on the status command, you will see a familiar screen where it is bringing up the
new pods.
But you'll also notice that in the screen we see that the old parts are getting terminated.
So one after the other, the new ports are being created with a new image, whereas old parts are getting
terminated.
So this is the default update strategy is set to rolling update cabinet as deployments are intelligent
enough to make sure that there are some running parts in the system so that the end users are not affected.
And it does the update one after the other.
So now let's run a CUCA to describe command and against the deployment and you'll see the same thing
under the events section as well.
So you can see that the older replica sets have been scaled down along with the replicas at I.D., which
were running the older image and the new ones are scaled up.
And here we can see the revision and the cause of change, which is Kupe cuddle edit deployment, which
we ran to change the image.
And here we take a look at the image quickly and we can see that it is running and the next one dot
one eight.
Right.
So now let's make yet another change to our deployment.
So right now it's running.
And the next version, one or one aide say we have a requirement to use a different image instead of
this.
So one way to do that is to use the CUCA to edit deployment command and edit the image name within the
YAML file.
That opens.
Another way to do is to use another command called Kupe Cuddle Set Image Deployment.
And the name of the deployment, which is my app deployment.
And here I'm going to use the name of the container, which is in Genex.
And this is a key value format.
A way of specifying the values of this should have the value of the new version that we're going to
set.
So let's make use of the Docker hub page.
And the new version that we will use is, say one dot one, a dash pote.
Again, I'm going to make use of the record command now the record option while I do this, so the changes
are recorded in the roll out history.
So now let's run a quick status comment and we can see that the older replicas are getting terminated,
which is for version one one wanted.
And we should have new replicas up and running for the version one one eight Dash Pearl.
So a quick look at the history shows us that it's all set.
And we have the new version, which is version number three, where we update the image you think the
typical set image command.
So let's quickly from the Cucuta's get parts command and make sure that all the six parts are running.
So let's say there is an issue with this new image that we used and it's not working well for the end
users.
We can revert back to the previous version by using the cute Cuttle undue command.
So right now we are on a revision three and we want to move to revision two, which has the engine X
one dot one version.
And to do this, we can run the parallel rollout, undo command with the name of the deployment.
So, again, let's run Cuddle Status Command and we see that it is making the change and it is bringing
down the older replicas of revision number three and then reverting back to revision number two, which
runs the engine X one dot one eight image.
Let's run a couple describe deployment command to make sure that this command, in fact, switched to
the correct image.
So it has reverted back to the next one or one eight image.
So now let's take a quick look at the roll out history and see what is recorded there.
Now, you'll see that we still have three revisions in total.
There is a new revision which is now created, which is number four.
But the revision number two is gone now.
That's because the fourth revision, which is the new revision, is essentially the just the same as
the second revision.
So it's reverted back to the same state that deployment was on when it was a provision to essentially
revision to has become the latest revision.
But it has changed the revision number from two to four.
And this is the same command that was recorded for revision to as well.
Now, let's try out another scenario.
So I'm going to use the cute little edit command again and make some more changes to our deployment.
Now, we know that right now the image should be on one one eight because we reported in the last step.
So now I'm going to make it change for the next container to use any image that does not exist.
So let me put something random here, such as does not exist.
And I'm going to save this file and we'll see the status.
Now.
So now you can see that the rollout status is stuck with this message that says waiting for a rollout
to finish and that three out of five new replicas have been updated.
He's going to stay there as it's trying to update to an image that does not exist and is not able to
pull that image from Docker Hub.
So the containers would fail.
So as a result, it will not successfully complete those deployment.
Now, let's go back and check in with Randi Cucuta.
Get deployment command.
And we provide the name of the deployment.
And here we see that the already state for this deployment is now five out of six.
Now up to date is three and available is five.
And let's also quickly run.
You could get parts command.
And here you note is that the number of pods which are running is actually five.
So here the deployment has terminated one of the existing pods on version one, the one eight.
And it is tried to create three new pods with new version of the image, the one that does not exist.
And that's why they are all in an error state.
So the status of the new pods are image pull-back off.
So all of these three have failed because the image by that name that was specified does not exist on
Docker Hub.
And as a result, it will keep the deployment in its current state until it is able to fetch this new
image from Docker Hub.
So even though we have specified her wrong image and there are three new parts which are trying to load
the new image, the application is not impacted.
And the end users will still be able to access the application on the old five running pods.
And this is because since we set the strategy, ruling up grade cabernets will only downgrade or destroy
the older pods once we have sufficient newer parts available.
So now let's take a look at the revision history and you will see that a new revision, which is a revision
number five, is recorded as well.
So now as a final step, let us do an undo deployment operation so that it goes from revision number
five, back to revision number four and fix the name of the image back to the next one, the one eight.
So for that, I'm going to use the rollout, undo command again.
And let's run the rollout status real quickly.
And now you'll see that it is successful.
So let's check the status of the parts.
And we see that the the one that it had to recreate has been created.
Twelve seconds ago and the remaining five parts were already in the correct version of one dot, one
eight.
And it terminated the three new parts which was trying to make use of the wrong image.
So now let us run a describe command.
And we will see that our application is now on the correct version, which is in the next one one eight.
And everything's good.
Well, that's it for now.
And I will see you the next lecture.