WEBVTT 00:05.500 --> 00:07.300 Hello and welcome to this lecture. 00:07.300 --> 00:11.830 In this lecture, we will talk about updates and rollbacks in a deployment. 00:12.990 --> 00:19.350 Before we look at how we upgrade our application, let's try to understand rollouts and versioning in 00:19.350 --> 00:20.070 a deployment. 00:21.160 --> 00:28.570 When you first create a deployment, it triggers a rollout, a new rollout creates a new deployment 00:28.570 --> 00:31.300 revision, let's call it revision one. 00:32.470 --> 00:38.110 In the future, when the application is upgraded, meaning when the container version is updated to 00:38.110 --> 00:46.660 a new one, a new rollout is triggered and a new deployment revision is created named revision to this 00:46.660 --> 00:53.350 helps us keep track of the changes made to our deployment and enables us to roll back to a previous 00:53.350 --> 00:55.800 version of deployment if necessary. 00:57.110 --> 01:03.500 You can see the status of your roll out by running the command KUB control rollout status, followed 01:03.500 --> 01:11.120 by the name of the deployment to see the revisions and history of rollout from the Cube control rollout 01:11.120 --> 01:14.300 history command, followed by the deployment name. 01:14.300 --> 01:18.830 And this will show you the revisions and history of our deployment. 01:21.180 --> 01:27.570 There are two types of deployment strategies, say, for example, you have five replicas of your Web 01:27.570 --> 01:29.520 application instance deployed. 01:30.360 --> 01:37.230 One way to upgrade these to a newer version is to destroy all of these and then create newer versions 01:37.230 --> 01:45.060 of application instances, meaning first destroy the five running instances and then deploy five new 01:45.060 --> 01:47.400 instances of the new application version. 01:48.090 --> 01:54.390 The problem with this, as you can imagine, is that during the period after the older versions are 01:54.390 --> 02:00.990 down and before any newer version is up, the application is down and inaccessible to users. 02:01.980 --> 02:09.000 This strategy is known as the recreate strategy and thankfully this is not the default deployment strategy. 02:09.840 --> 02:14.130 The second strategy is where we did not destroy all of them at once. 02:14.490 --> 02:19.800 Instead, we take down the older version and bring up a newer version, one by one. 02:20.520 --> 02:24.990 This way, the application never goes down and the upgrade is seamless. 02:25.860 --> 02:31.830 Remember, if you do not specify a strategy while creating the deployment, it will assume it to be 02:31.830 --> 02:32.310 rolling. 02:32.310 --> 02:32.790 Update. 02:33.060 --> 02:38.210 In other words, rolling update is the default deployment strategy. 02:40.230 --> 02:42.040 So we talked about upgrades. 02:42.510 --> 02:49.140 How exactly do you update your deployment when I say update, it could be different things, such as 02:49.140 --> 02:54.900 updating your application version by updating the version of docker containers used, updating their 02:54.900 --> 02:57.960 labels or updating the number of replicas, etc.. 02:58.590 --> 03:03.990 Since we already have a deployment definition file, it is easy for us to modify this file. 03:04.470 --> 03:10.650 Once we make the necessary changes, we run the cube control appli command to apply the changes. 03:12.300 --> 03:19.170 A new rollout is triggered and a new revision of the deployment is created, but there is another way 03:19.170 --> 03:26.130 to do the same thing you could use to keep control set, image command to update the image of your application. 03:26.730 --> 03:33.840 But remember, doing it this way will result in the deployment definition file having a different configuration. 03:34.080 --> 03:40.130 So you must be careful when using the same definition file to make changes in the future. 03:42.310 --> 03:48.010 The difference between the recreate and rolling update strategies can also be seen when you view the 03:48.010 --> 03:55.210 deployments in detail from the cube control, describe deployment command to see the detailed information 03:55.210 --> 03:56.460 regarding the deployments. 03:57.160 --> 04:04.090 You will notice when the recreated strategy was used, the events indicate that the old Republican said 04:04.120 --> 04:09.700 was scaled down to zero first and then the new replica sets scaled up to five. 04:10.360 --> 04:17.050 However, when the rolling update strategy was used, the old replica set was scaled down one at a time, 04:17.350 --> 04:21.610 simultaneously scaling up the new replica set, one at a time. 04:22.990 --> 04:29.770 Let's look at how a deployment performs an upgrade under the hood when a new deployment is created, 04:29.770 --> 04:37.540 say, to deploy five replicas, it first creates a replica set automatically, which in turn creates 04:37.540 --> 04:40.770 the number of parts required to meet the number of replicas. 04:41.590 --> 04:47.980 When you upgrade your application, as we saw in the previous slide, the community's deployment object 04:47.980 --> 04:55.390 creates a new replica set under the hood and starts deploying the containers there at the same time 04:55.390 --> 05:00.520 taking down the parts in the old replica set following a rolling update strategy. 05:01.530 --> 05:07.850 This can be seen when you try to list the replica sets using the cube control, get replica sets command 05:08.250 --> 05:14.610 here we see the old replica set with zero parts and the new replica set with five parts. 05:15.670 --> 05:21.370 Say, for instance, once you upgrade your application, you realize something isn't very right, something's 05:21.370 --> 05:25.180 wrong with the new version of build you used to upgrade. 05:25.480 --> 05:28.990 So you would like to roll back your update coordinators. 05:28.990 --> 05:36.520 Deployments allow you to roll back to a previous revision to undo a change, run the cube control rollout, 05:36.520 --> 05:39.730 undo command followed by the name of the deployment. 05:40.420 --> 05:46.750 The deployment will then destroy the part in the new replica set and bring the older ones up in the 05:46.750 --> 05:47.920 old replica set. 05:48.040 --> 05:51.580 And your application is back to its older format. 05:52.180 --> 05:58.420 When you compare the output of the cube control, get replica sets command before and after the roll 05:58.420 --> 06:02.980 back, you will be able to notice the difference before the roll back. 06:03.280 --> 06:11.680 The first replica set had zero parts and new replicas that had five parts and this is reversed after 06:11.680 --> 06:13.250 the rollback is finished. 06:13.570 --> 06:19.150 To summarize the commands real quick, use the cube control, create command to create the deployment, 06:19.690 --> 06:27.670 get DEPLOYMENT'S command to list the deployments, apply and set image commands to update the deployments, 06:28.090 --> 06:36.160 and roll out status commands to see the status of rollout's and roll out undue command to roll back 06:36.160 --> 06:37.930 a deployment operation. 06:45.770 --> 06:47.060 That's it for this lecture. 06:47.090 --> 06:50.720 We will now head over to a demo and I will see you in the next lecture.