WEBVTT 00:00.870 --> 00:06.720 In this demo, we're going to look at updates and rollbacks for deployments in Cuba. 00:07.840 --> 00:13.100 So in the previous demo, we used a deployment definition file, which is located in the deployment 00:13.100 --> 00:14.900 directory of our project folder. 00:15.740 --> 00:18.770 The name of the deployment is my app deployment. 00:19.580 --> 00:23.440 And we have updated the file to use six replicas all year. 00:23.900 --> 00:27.530 It was three and it is using an index image. 00:28.250 --> 00:32.810 So to create this deployment, we will use the Cube Cuttle Create Deployment Command. 00:33.380 --> 00:38.660 But before that, let's quickly check and make sure that there are no objects created in the cluster. 00:39.750 --> 00:39.950 OK. 00:40.130 --> 00:40.910 That looks good. 00:41.730 --> 00:48.620 So I'm going to run the cube to create command with the dash F option to specify the deployment of Yamal 00:49.040 --> 00:49.940 has the file. 00:50.570 --> 00:53.300 So once we run this command, the deployment is created. 00:53.990 --> 01:00.590 Now, let's make use of a new command called the Cube Cuttle Rollout Status Command with the deployment 01:00.590 --> 01:03.440 name to check the status of the deployment. 01:04.400 --> 01:11.180 So as soon as I run this command, I see that the deployment, my app dash deployment has been successfully 01:11.180 --> 01:11.750 rolled out. 01:12.740 --> 01:19.790 Now, if we had run this command more quickly, like right after we ran the command to create the deployment, 01:20.390 --> 01:22.160 we would have seen a different status. 01:22.760 --> 01:25.490 So let's quickly delete this deployment. 01:26.060 --> 01:31.730 And what I'm going to do now is I'm going to create the deployment again and I'm going to quickly run 01:31.730 --> 01:33.640 the status command right after I do it. 01:35.100 --> 01:41.430 As soon as I run this command, it will show you the status of each replica which is being brought up. 01:41.610 --> 01:45.480 So remember that we have used six replicas in total. 01:45.960 --> 01:53.400 And as soon as we are on the status command after deleting the deployment, we see that it tries to 01:53.400 --> 01:55.800 bring out the pod one at a time. 01:56.810 --> 02:01.410 So here we have zero out of six and then one out of six. 02:01.430 --> 02:02.480 Two out of six, et cetera. 02:02.510 --> 02:07.640 So until all the six pots are up and running, you'll see a status message related to that. 02:08.090 --> 02:13.730 And only after all the parts have been deployed successfully will coordinators consider the deployment 02:14.150 --> 02:15.260 to be successful. 02:16.040 --> 02:21.980 So once deployed, we use another command to see the history of the deployment. 02:22.160 --> 02:24.950 And for this, we will use the same command as before. 02:25.430 --> 02:28.790 But instead of status, we will use the roll out. 02:28.790 --> 02:29.320 History. 02:29.360 --> 02:29.780 Command. 02:33.360 --> 02:40.770 Now, you can see that the my AB deployment has one revision, which is the one that we just did, that 02:40.770 --> 02:42.420 was creating the deployment itself. 02:43.110 --> 02:50.460 And there is also a column called Change Costs, which you'll notice that has there is no change cost 02:50.460 --> 02:51.200 specified. 02:52.140 --> 02:59.100 And that is because we did not specifically ask it to record the cause of change while we created the 02:59.100 --> 02:59.670 deployment. 03:00.700 --> 03:02.500 So let's go back and fix that. 03:02.530 --> 03:05.200 So we'll delete the deployment again. 03:10.110 --> 03:13.290 Let's wait for the pod to be terminated. 03:13.650 --> 03:18.630 So now it's in terminating state and let's wait for all of them to go away. 03:19.560 --> 03:24.030 So now that all of them have been deleted, I'm going to run the same command as before. 03:24.060 --> 03:28.980 But this time I'm going to use the dash dash record option. 03:29.390 --> 03:36.840 The record option instructs Cabinet to record the cause of change, to execute that command now. 03:37.630 --> 03:42.750 And again, I'll run the roll out status command to watch the status of deployment and wait for all 03:42.750 --> 03:46.230 the parts to be up and for the deployment to be successful. 03:50.300 --> 03:56.110 And now let's run the history comment again, and this time you'll see that against the revision. 03:56.140 --> 04:02.260 There is a change course which is mentioned, which is essentially the same command that we ran to create 04:02.290 --> 04:02.920 the deployment. 04:03.450 --> 04:10.060 But because we use the dash dash record option, it is recording the command here. 04:10.990 --> 04:13.900 So now let us try to make a change to the deployment. 04:14.830 --> 04:19.780 So first, let's run the cubicle, describe a command with the name of the deployment. 04:22.300 --> 04:27.850 And this pulls up the additional information and you'll see that in the annotations section, it has 04:27.850 --> 04:32.050 recorded the command that we used to run this to create this deployment. 04:32.650 --> 04:35.830 And we know that it is running six replicas. 04:36.420 --> 04:41.670 And if you scroll down, you'll see that the image of this container, of this deployment is engine 04:41.670 --> 04:41.910 X. 04:42.010 --> 04:43.810 So let's make a change to that. 04:46.270 --> 04:50.340 And for this, I'll make use of the cubicle edit deployment command. 04:50.930 --> 04:57.500 And I'm also going to use the dash dash record option so that the cause of change is tracked in the 04:57.500 --> 04:58.610 revision history. 04:59.240 --> 05:03.350 So what I'm going to do now is I'm going to look up image. 05:04.330 --> 05:06.650 And currently, it is set to end Genex. 05:07.400 --> 05:09.560 So we will change this to a lower version. 05:10.060 --> 05:13.220 And so this is using the latest version of Engine X currently. 05:13.250 --> 05:18.030 And what we'll do is we will change it to another version, a lower version. 05:18.050 --> 05:21.500 And for that, let's make use of the Docker hub documentation. 05:22.040 --> 05:24.920 So here I am at Docker Hub and I'm looking at. 05:25.870 --> 05:32.040 And Genex and you'll see that the current version, since we did not specify a target, is one dot one 05:32.040 --> 05:32.520 nine. 05:33.000 --> 05:37.200 As of this recording and let us make use of an older version, one out, one eight. 05:37.770 --> 05:39.210 So back to the terminal. 05:39.220 --> 05:41.760 I'm going to change the version to one dot one eight. 05:42.360 --> 05:45.600 And for that, I'll add a colon and I'll mention the word number here. 05:47.080 --> 05:53.460 And once I'm done with the changes, I'll use the WQ to save and exit the editor. 05:54.100 --> 06:01.990 And now if you're on the status command, you will see a familiar screen where it is bringing up the 06:01.990 --> 06:02.740 new pods. 06:03.370 --> 06:08.260 But you'll also notice that in the screen we see that the old parts are getting terminated. 06:08.860 --> 06:15.190 So one after the other, the new ports are being created with a new image, whereas old parts are getting 06:15.190 --> 06:15.640 terminated. 06:16.270 --> 06:23.620 So this is the default update strategy is set to rolling update cabinet as deployments are intelligent 06:23.620 --> 06:29.530 enough to make sure that there are some running parts in the system so that the end users are not affected. 06:29.590 --> 06:32.230 And it does the update one after the other. 06:33.100 --> 06:39.310 So now let's run a CUCA to describe command and against the deployment and you'll see the same thing 06:39.400 --> 06:41.290 under the events section as well. 06:41.920 --> 06:48.910 So you can see that the older replica sets have been scaled down along with the replicas at I.D., which 06:48.910 --> 06:52.030 were running the older image and the new ones are scaled up. 06:52.450 --> 06:59.020 And here we can see the revision and the cause of change, which is Kupe cuddle edit deployment, which 06:59.020 --> 07:00.400 we ran to change the image. 07:01.090 --> 07:07.780 And here we take a look at the image quickly and we can see that it is running and the next one dot 07:07.780 --> 07:08.410 one eight. 07:09.790 --> 07:10.030 Right. 07:10.060 --> 07:13.600 So now let's make yet another change to our deployment. 07:14.140 --> 07:15.740 So right now it's running. 07:15.770 --> 07:21.190 And the next version, one or one aide say we have a requirement to use a different image instead of 07:21.190 --> 07:21.550 this. 07:22.120 --> 07:28.900 So one way to do that is to use the CUCA to edit deployment command and edit the image name within the 07:28.900 --> 07:29.600 YAML file. 07:29.650 --> 07:30.340 That opens. 07:31.370 --> 07:37.520 Another way to do is to use another command called Kupe Cuddle Set Image Deployment. 07:37.640 --> 07:41.010 And the name of the deployment, which is my app deployment. 07:41.750 --> 07:45.590 And here I'm going to use the name of the container, which is in Genex. 07:46.430 --> 07:48.860 And this is a key value format. 07:49.050 --> 07:54.440 A way of specifying the values of this should have the value of the new version that we're going to 07:54.440 --> 07:54.770 set. 07:55.310 --> 07:57.380 So let's make use of the Docker hub page. 07:57.950 --> 08:02.810 And the new version that we will use is, say one dot one, a dash pote. 08:12.150 --> 08:17.640 Again, I'm going to make use of the record command now the record option while I do this, so the changes 08:17.640 --> 08:19.500 are recorded in the roll out history. 08:20.070 --> 08:26.340 So now let's run a quick status comment and we can see that the older replicas are getting terminated, 08:27.240 --> 08:28.970 which is for version one one wanted. 08:29.260 --> 08:34.420 And we should have new replicas up and running for the version one one eight Dash Pearl. 08:35.280 --> 08:38.730 So a quick look at the history shows us that it's all set. 08:38.910 --> 08:44.110 And we have the new version, which is version number three, where we update the image you think the 08:44.190 --> 08:45.870 typical set image command. 08:46.800 --> 08:53.160 So let's quickly from the Cucuta's get parts command and make sure that all the six parts are running. 08:53.910 --> 08:59.250 So let's say there is an issue with this new image that we used and it's not working well for the end 08:59.250 --> 08:59.790 users. 09:00.420 --> 09:05.850 We can revert back to the previous version by using the cute Cuttle undue command. 09:06.360 --> 09:12.210 So right now we are on a revision three and we want to move to revision two, which has the engine X 09:12.630 --> 09:14.090 one dot one version. 09:14.730 --> 09:20.520 And to do this, we can run the parallel rollout, undo command with the name of the deployment. 09:24.950 --> 09:32.330 So, again, let's run Cuddle Status Command and we see that it is making the change and it is bringing 09:32.330 --> 09:38.900 down the older replicas of revision number three and then reverting back to revision number two, which 09:38.900 --> 09:41.510 runs the engine X one dot one eight image. 09:42.830 --> 09:48.770 Let's run a couple describe deployment command to make sure that this command, in fact, switched to 09:48.770 --> 09:49.640 the correct image. 09:50.380 --> 09:53.720 So it has reverted back to the next one or one eight image. 09:54.680 --> 09:59.410 So now let's take a quick look at the roll out history and see what is recorded there. 10:00.320 --> 10:04.010 Now, you'll see that we still have three revisions in total. 10:04.100 --> 10:08.030 There is a new revision which is now created, which is number four. 10:08.690 --> 10:12.520 But the revision number two is gone now. 10:12.650 --> 10:18.290 That's because the fourth revision, which is the new revision, is essentially the just the same as 10:18.290 --> 10:19.310 the second revision. 10:20.180 --> 10:27.350 So it's reverted back to the same state that deployment was on when it was a provision to essentially 10:27.410 --> 10:30.770 revision to has become the latest revision. 10:30.830 --> 10:34.340 But it has changed the revision number from two to four. 10:35.210 --> 10:40.360 And this is the same command that was recorded for revision to as well. 10:41.570 --> 10:43.850 Now, let's try out another scenario. 10:43.920 --> 10:49.640 So I'm going to use the cute little edit command again and make some more changes to our deployment. 10:50.150 --> 10:56.630 Now, we know that right now the image should be on one one eight because we reported in the last step. 10:57.260 --> 11:02.510 So now I'm going to make it change for the next container to use any image that does not exist. 11:03.050 --> 11:07.340 So let me put something random here, such as does not exist. 11:07.640 --> 11:13.250 And I'm going to save this file and we'll see the status. 11:13.280 --> 11:13.640 Now. 11:16.520 --> 11:23.870 So now you can see that the rollout status is stuck with this message that says waiting for a rollout 11:23.900 --> 11:29.180 to finish and that three out of five new replicas have been updated. 11:29.600 --> 11:36.110 He's going to stay there as it's trying to update to an image that does not exist and is not able to 11:36.110 --> 11:38.300 pull that image from Docker Hub. 11:38.510 --> 11:40.070 So the containers would fail. 11:40.820 --> 11:44.450 So as a result, it will not successfully complete those deployment. 11:45.470 --> 11:48.880 Now, let's go back and check in with Randi Cucuta. 11:48.980 --> 11:50.210 Get deployment command. 11:53.710 --> 11:55.380 And we provide the name of the deployment. 11:56.720 --> 12:02.180 And here we see that the already state for this deployment is now five out of six. 12:02.870 --> 12:05.630 Now up to date is three and available is five. 12:06.420 --> 12:08.480 And let's also quickly run. 12:08.560 --> 12:10.910 You could get parts command. 12:12.960 --> 12:17.460 And here you note is that the number of pods which are running is actually five. 12:18.150 --> 12:24.300 So here the deployment has terminated one of the existing pods on version one, the one eight. 12:24.840 --> 12:31.230 And it is tried to create three new pods with new version of the image, the one that does not exist. 12:31.440 --> 12:33.810 And that's why they are all in an error state. 12:34.710 --> 12:38.700 So the status of the new pods are image pull-back off. 12:38.760 --> 12:44.520 So all of these three have failed because the image by that name that was specified does not exist on 12:44.520 --> 12:45.150 Docker Hub. 12:45.630 --> 12:51.570 And as a result, it will keep the deployment in its current state until it is able to fetch this new 12:51.570 --> 12:52.770 image from Docker Hub. 12:54.040 --> 13:01.030 So even though we have specified her wrong image and there are three new parts which are trying to load 13:01.120 --> 13:04.120 the new image, the application is not impacted. 13:04.570 --> 13:10.770 And the end users will still be able to access the application on the old five running pods. 13:11.380 --> 13:19.690 And this is because since we set the strategy, ruling up grade cabernets will only downgrade or destroy 13:19.690 --> 13:25.720 the older pods once we have sufficient newer parts available. 13:26.500 --> 13:30.730 So now let's take a look at the revision history and you will see that a new revision, which is a revision 13:30.730 --> 13:33.040 number five, is recorded as well. 13:33.130 --> 13:39.520 So now as a final step, let us do an undo deployment operation so that it goes from revision number 13:39.520 --> 13:46.120 five, back to revision number four and fix the name of the image back to the next one, the one eight. 13:46.690 --> 13:50.320 So for that, I'm going to use the rollout, undo command again. 13:51.620 --> 13:54.830 And let's run the rollout status real quickly. 13:54.860 --> 13:57.800 And now you'll see that it is successful. 13:58.310 --> 14:00.200 So let's check the status of the parts. 14:00.230 --> 14:04.790 And we see that the the one that it had to recreate has been created. 14:04.860 --> 14:10.370 Twelve seconds ago and the remaining five parts were already in the correct version of one dot, one 14:10.370 --> 14:10.670 eight. 14:11.500 --> 14:16.200 And it terminated the three new parts which was trying to make use of the wrong image. 14:17.240 --> 14:20.450 So now let us run a describe command. 14:20.600 --> 14:27.680 And we will see that our application is now on the correct version, which is in the next one one eight. 14:28.910 --> 14:29.860 And everything's good. 14:30.960 --> 14:32.430 Well, that's it for now. 14:32.740 --> 14:34.680 And I will see you the next lecture.