Hello and welcome to this lecture.
In this lecture, we will talk about updates and rollbacks in a deployment.
Before we look at how we upgrade our application, let's try to understand rollouts and versioning in
a deployment.
When you first create a deployment, it triggers a rollout, a new rollout creates a new deployment
revision, let's call it revision one.
In the future, when the application is upgraded, meaning when the container version is updated to
a new one, a new rollout is triggered and a new deployment revision is created named revision to this
helps us keep track of the changes made to our deployment and enables us to roll back to a previous
version of deployment if necessary.
You can see the status of your roll out by running the command KUB control rollout status, followed
by the name of the deployment to see the revisions and history of rollout from the Cube control rollout
history command, followed by the deployment name.
And this will show you the revisions and history of our deployment.
There are two types of deployment strategies, say, for example, you have five replicas of your Web
application instance deployed.
One way to upgrade these to a newer version is to destroy all of these and then create newer versions
of application instances, meaning first destroy the five running instances and then deploy five new
instances of the new application version.
The problem with this, as you can imagine, is that during the period after the older versions are
down and before any newer version is up, the application is down and inaccessible to users.
This strategy is known as the recreate strategy and thankfully this is not the default deployment strategy.
The second strategy is where we did not destroy all of them at once.
Instead, we take down the older version and bring up a newer version, one by one.
This way, the application never goes down and the upgrade is seamless.
Remember, if you do not specify a strategy while creating the deployment, it will assume it to be
rolling.
Update.
In other words, rolling update is the default deployment strategy.
So we talked about upgrades.
How exactly do you update your deployment when I say update, it could be different things, such as
updating your application version by updating the version of docker containers used, updating their
labels or updating the number of replicas, etc..
Since we already have a deployment definition file, it is easy for us to modify this file.
Once we make the necessary changes, we run the cube control appli command to apply the changes.
A new rollout is triggered and a new revision of the deployment is created, but there is another way
to do the same thing you could use to keep control set, image command to update the image of your application.
But remember, doing it this way will result in the deployment definition file having a different configuration.
So you must be careful when using the same definition file to make changes in the future.
The difference between the recreate and rolling update strategies can also be seen when you view the
deployments in detail from the cube control, describe deployment command to see the detailed information
regarding the deployments.
You will notice when the recreated strategy was used, the events indicate that the old Republican said
was scaled down to zero first and then the new replica sets scaled up to five.
However, when the rolling update strategy was used, the old replica set was scaled down one at a time,
simultaneously scaling up the new replica set, one at a time.
Let's look at how a deployment performs an upgrade under the hood when a new deployment is created,
say, to deploy five replicas, it first creates a replica set automatically, which in turn creates
the number of parts required to meet the number of replicas.
When you upgrade your application, as we saw in the previous slide, the community's deployment object
creates a new replica set under the hood and starts deploying the containers there at the same time
taking down the parts in the old replica set following a rolling update strategy.
This can be seen when you try to list the replica sets using the cube control, get replica sets command
here we see the old replica set with zero parts and the new replica set with five parts.
Say, for instance, once you upgrade your application, you realize something isn't very right, something's
wrong with the new version of build you used to upgrade.
So you would like to roll back your update coordinators.
Deployments allow you to roll back to a previous revision to undo a change, run the cube control rollout,
undo command followed by the name of the deployment.
The deployment will then destroy the part in the new replica set and bring the older ones up in the
old replica set.
And your application is back to its older format.
When you compare the output of the cube control, get replica sets command before and after the roll
back, you will be able to notice the difference before the roll back.
The first replica set had zero parts and new replicas that had five parts and this is reversed after
the rollback is finished.
To summarize the commands real quick, use the cube control, create command to create the deployment,
get DEPLOYMENT'S command to list the deployments, apply and set image commands to update the deployments,
and roll out status commands to see the status of rollout's and roll out undue command to roll back
a deployment operation.
That's it for this lecture.
We will now head over to a demo and I will see you in the next lecture.