1 00:00:05,500 --> 00:00:07,300 Hello and welcome to this lecture. 2 00:00:07,300 --> 00:00:11,830 In this lecture, we will talk about updates and rollbacks in a deployment. 3 00:00:12,990 --> 00:00:19,350 Before we look at how we upgrade our application, let's try to understand rollouts and versioning in 4 00:00:19,350 --> 00:00:20,070 a deployment. 5 00:00:21,160 --> 00:00:28,570 When you first create a deployment, it triggers a rollout, a new rollout creates a new deployment 6 00:00:28,570 --> 00:00:31,300 revision, let's call it revision one. 7 00:00:32,470 --> 00:00:38,110 In the future, when the application is upgraded, meaning when the container version is updated to 8 00:00:38,110 --> 00:00:46,660 a new one, a new rollout is triggered and a new deployment revision is created named revision to this 9 00:00:46,660 --> 00:00:53,350 helps us keep track of the changes made to our deployment and enables us to roll back to a previous 10 00:00:53,350 --> 00:00:55,800 version of deployment if necessary. 11 00:00:57,110 --> 00:01:03,500 You can see the status of your roll out by running the command KUB control rollout status, followed 12 00:01:03,500 --> 00:01:11,120 by the name of the deployment to see the revisions and history of rollout from the Cube control rollout 13 00:01:11,120 --> 00:01:14,300 history command, followed by the deployment name. 14 00:01:14,300 --> 00:01:18,830 And this will show you the revisions and history of our deployment. 15 00:01:21,180 --> 00:01:27,570 There are two types of deployment strategies, say, for example, you have five replicas of your Web 16 00:01:27,570 --> 00:01:29,520 application instance deployed. 17 00:01:30,360 --> 00:01:37,230 One way to upgrade these to a newer version is to destroy all of these and then create newer versions 18 00:01:37,230 --> 00:01:45,060 of application instances, meaning first destroy the five running instances and then deploy five new 19 00:01:45,060 --> 00:01:47,400 instances of the new application version. 20 00:01:48,090 --> 00:01:54,390 The problem with this, as you can imagine, is that during the period after the older versions are 21 00:01:54,390 --> 00:02:00,990 down and before any newer version is up, the application is down and inaccessible to users. 22 00:02:01,980 --> 00:02:09,000 This strategy is known as the recreate strategy and thankfully this is not the default deployment strategy. 23 00:02:09,840 --> 00:02:14,130 The second strategy is where we did not destroy all of them at once. 24 00:02:14,490 --> 00:02:19,800 Instead, we take down the older version and bring up a newer version, one by one. 25 00:02:20,520 --> 00:02:24,990 This way, the application never goes down and the upgrade is seamless. 26 00:02:25,860 --> 00:02:31,830 Remember, if you do not specify a strategy while creating the deployment, it will assume it to be 27 00:02:31,830 --> 00:02:32,310 rolling. 28 00:02:32,310 --> 00:02:32,790 Update. 29 00:02:33,060 --> 00:02:38,210 In other words, rolling update is the default deployment strategy. 30 00:02:40,230 --> 00:02:42,040 So we talked about upgrades. 31 00:02:42,510 --> 00:02:49,140 How exactly do you update your deployment when I say update, it could be different things, such as 32 00:02:49,140 --> 00:02:54,900 updating your application version by updating the version of docker containers used, updating their 33 00:02:54,900 --> 00:02:57,960 labels or updating the number of replicas, etc.. 34 00:02:58,590 --> 00:03:03,990 Since we already have a deployment definition file, it is easy for us to modify this file. 35 00:03:04,470 --> 00:03:10,650 Once we make the necessary changes, we run the cube control appli command to apply the changes. 36 00:03:12,300 --> 00:03:19,170 A new rollout is triggered and a new revision of the deployment is created, but there is another way 37 00:03:19,170 --> 00:03:26,130 to do the same thing you could use to keep control set, image command to update the image of your application. 38 00:03:26,730 --> 00:03:33,840 But remember, doing it this way will result in the deployment definition file having a different configuration. 39 00:03:34,080 --> 00:03:40,130 So you must be careful when using the same definition file to make changes in the future. 40 00:03:42,310 --> 00:03:48,010 The difference between the recreate and rolling update strategies can also be seen when you view the 41 00:03:48,010 --> 00:03:55,210 deployments in detail from the cube control, describe deployment command to see the detailed information 42 00:03:55,210 --> 00:03:56,460 regarding the deployments. 43 00:03:57,160 --> 00:04:04,090 You will notice when the recreated strategy was used, the events indicate that the old Republican said 44 00:04:04,120 --> 00:04:09,700 was scaled down to zero first and then the new replica sets scaled up to five. 45 00:04:10,360 --> 00:04:17,050 However, when the rolling update strategy was used, the old replica set was scaled down one at a time, 46 00:04:17,350 --> 00:04:21,610 simultaneously scaling up the new replica set, one at a time. 47 00:04:22,990 --> 00:04:29,770 Let's look at how a deployment performs an upgrade under the hood when a new deployment is created, 48 00:04:29,770 --> 00:04:37,540 say, to deploy five replicas, it first creates a replica set automatically, which in turn creates 49 00:04:37,540 --> 00:04:40,770 the number of parts required to meet the number of replicas. 50 00:04:41,590 --> 00:04:47,980 When you upgrade your application, as we saw in the previous slide, the community's deployment object 51 00:04:47,980 --> 00:04:55,390 creates a new replica set under the hood and starts deploying the containers there at the same time 52 00:04:55,390 --> 00:05:00,520 taking down the parts in the old replica set following a rolling update strategy. 53 00:05:01,530 --> 00:05:07,850 This can be seen when you try to list the replica sets using the cube control, get replica sets command 54 00:05:08,250 --> 00:05:14,610 here we see the old replica set with zero parts and the new replica set with five parts. 55 00:05:15,670 --> 00:05:21,370 Say, for instance, once you upgrade your application, you realize something isn't very right, something's 56 00:05:21,370 --> 00:05:25,180 wrong with the new version of build you used to upgrade. 57 00:05:25,480 --> 00:05:28,990 So you would like to roll back your update coordinators. 58 00:05:28,990 --> 00:05:36,520 Deployments allow you to roll back to a previous revision to undo a change, run the cube control rollout, 59 00:05:36,520 --> 00:05:39,730 undo command followed by the name of the deployment. 60 00:05:40,420 --> 00:05:46,750 The deployment will then destroy the part in the new replica set and bring the older ones up in the 61 00:05:46,750 --> 00:05:47,920 old replica set. 62 00:05:48,040 --> 00:05:51,580 And your application is back to its older format. 63 00:05:52,180 --> 00:05:58,420 When you compare the output of the cube control, get replica sets command before and after the roll 64 00:05:58,420 --> 00:06:02,980 back, you will be able to notice the difference before the roll back. 65 00:06:03,280 --> 00:06:11,680 The first replica set had zero parts and new replicas that had five parts and this is reversed after 66 00:06:11,680 --> 00:06:13,250 the rollback is finished. 67 00:06:13,570 --> 00:06:19,150 To summarize the commands real quick, use the cube control, create command to create the deployment, 68 00:06:19,690 --> 00:06:27,670 get DEPLOYMENT'S command to list the deployments, apply and set image commands to update the deployments, 69 00:06:28,090 --> 00:06:36,160 and roll out status commands to see the status of rollout's and roll out undue command to roll back 70 00:06:36,160 --> 00:06:37,930 a deployment operation. 71 00:06:45,770 --> 00:06:47,060 That's it for this lecture. 72 00:06:47,090 --> 00:06:50,720 We will now head over to a demo and I will see you in the next lecture.