1 00:00:00,850 --> 00:00:05,790 In the last section we updated our multi client image and then we push the result off to docker hub. 2 00:00:06,010 --> 00:00:10,780 We're now going to move on to step three which is to somehow convince our deployment to recreate or 3 00:00:10,840 --> 00:00:15,550 otherwise update all of our pods with the latest version of that multi client image. 4 00:00:15,550 --> 00:00:21,070 Now unfortunately step 3 right here is very challenging and there's not a very good solution around 5 00:00:21,070 --> 00:00:21,580 it. 6 00:00:21,610 --> 00:00:25,720 Now that might be very surprising but I just want to be very clear with you in the world of Kuber Nettie's 7 00:00:25,930 --> 00:00:31,720 convincing a deployment to recreate our pods with the latest version of an image is not the easiest 8 00:00:31,720 --> 00:00:33,060 thing in the world to do. 9 00:00:33,370 --> 00:00:36,780 So inside this section we're going to take a look at why this is challenging. 10 00:00:36,850 --> 00:00:40,750 And then we're going to look at a couple of different ways to solve this problem. 11 00:00:40,780 --> 00:00:45,550 Now before we start talking about why this is challenging or any of the solutions I want to very quickly 12 00:00:45,550 --> 00:00:51,700 mention to you that on the Get Out page for the Kooper Nettie's repo you can go to the issues board 13 00:00:51,910 --> 00:00:56,820 and reference issue number 3 3 6 6 4 to get to this issue in particular. 14 00:00:56,830 --> 00:01:00,720 You can just type that issue number directly into your address bar. 15 00:01:00,730 --> 00:01:06,430 This is a entire issue with a ton of different conversation going on here talking about how challenging 16 00:01:06,430 --> 00:01:13,930 it is and suggesting different ways of convincing your deployment file to somehow update all the pods 17 00:01:13,930 --> 00:01:14,990 that it is managing. 18 00:01:15,160 --> 00:01:20,350 So I do recommend maybe taking a quick glance at this issue thread and getting a better idea of the 19 00:01:20,350 --> 00:01:23,370 root causes here and some of the different ways of solving the problem. 20 00:01:24,220 --> 00:01:30,250 All right so let's take a look first at why this is so challenging to get a deployment to update the 21 00:01:30,280 --> 00:01:33,790 image that is being used by all the pods that it manages. 22 00:01:33,790 --> 00:01:38,650 I want to first remind you that in order to update any object inside of our Cuban Nadya's cluster we 23 00:01:38,650 --> 00:01:44,380 make a change to our deployment file and then we send the deployment file off to the CUV Seitel command 24 00:01:44,380 --> 00:01:47,260 line tool with something looks like this right here right. 25 00:01:47,260 --> 00:01:50,070 We do the cube Seitel apply. 26 00:01:50,090 --> 00:01:55,480 Now the issue that we have right now is that inside of our deployment file there's nothing inside of 27 00:01:55,490 --> 00:02:01,470 here that says hey I want to use some particular version of our multi client image. 28 00:02:01,580 --> 00:02:07,730 So when we send an update to multi client off to Dharker hub when we make our updated version of that 29 00:02:07,760 --> 00:02:12,080 image and we send it off there's nothing that we can kind of turn back around to this file with and 30 00:02:12,080 --> 00:02:15,740 say hey I want you to now use like the latest image. 31 00:02:15,830 --> 00:02:21,260 Now the reason that's such a big deal is that if we try to take an unchanged configuration file and 32 00:02:21,320 --> 00:02:27,410 apply it with Cuba TTL if there's no changes in the configuration file then CUV still apply. 33 00:02:27,410 --> 00:02:30,070 It's just going to flat out reject the file. 34 00:02:30,080 --> 00:02:31,580 Let's try that out right now. 35 00:02:31,580 --> 00:02:37,410 Remember we've already applied this file and we've made no changes to it since we last authored it. 36 00:02:37,740 --> 00:02:45,850 It looks to me since we last applied it to back my command line I'll do a cube Seitel apply dash f client 37 00:02:45,850 --> 00:02:46,540 deployment. 38 00:02:46,590 --> 00:02:51,920 YAML and then when I run this command it's going to tell us that the file is unchanged. 39 00:02:52,080 --> 00:02:57,810 And so the entire file the entire apply command is just flat out rejected because the config that we're 40 00:02:57,810 --> 00:03:02,300 trying to upload is identical to the last config we put in place. 41 00:03:02,310 --> 00:03:06,360 Now when you put this file up it's unchanged that means totally rejected. 42 00:03:06,360 --> 00:03:11,970 So there's nothing inside that process that says oh we should probably go and see if a new version of 43 00:03:12,060 --> 00:03:18,810 this image is available that does not occur and no point when you try to upload or re-applied that config 44 00:03:18,810 --> 00:03:19,400 file. 45 00:03:19,530 --> 00:03:22,870 It does not try to see if a new version of this image is available. 46 00:03:22,870 --> 00:03:26,210 And so the entire apply command just flat out rejected. 47 00:03:26,400 --> 00:03:28,620 That's why this is such a big issue. 48 00:03:29,000 --> 00:03:29,230 OK. 49 00:03:29,250 --> 00:03:34,860 So with all that in mind we're now going to look at a diagram that's going to lay out three possible 50 00:03:34,860 --> 00:03:38,060 solutions that we can use to get around this issue. 51 00:03:38,130 --> 00:03:41,190 So none of these solutions are really that great. 52 00:03:41,220 --> 00:03:43,580 I'll be honest with you none of them are really that good. 53 00:03:43,590 --> 00:03:45,820 They're kind of the best of a bad situation. 54 00:03:46,540 --> 00:03:46,750 OK. 55 00:03:46,770 --> 00:03:51,030 So here's the first option we can use to get our deployment to update with the latest version of that 56 00:03:51,030 --> 00:03:51,730 image. 57 00:03:51,840 --> 00:03:56,670 We could manually delete all the pods that are managed by that deployment. 58 00:03:56,700 --> 00:04:01,980 Now when we manually delete a pod that is managed by deployment the deployment is going to very quickly 59 00:04:01,980 --> 00:04:07,910 notice that the deploy that the pod is missing and it's going to attempt to recreate it automatically. 60 00:04:08,310 --> 00:04:15,120 So in other words if we go over to our terminal right now end to a cube Seitel get pods and then attempt 61 00:04:15,120 --> 00:04:17,120 to delete this pod right here. 62 00:04:17,160 --> 00:04:22,950 The deployment will very quickly notice that it has a missing pod and the deployment will recreate this 63 00:04:22,950 --> 00:04:24,530 thing automatically. 64 00:04:24,540 --> 00:04:29,490 So our hope there would be that when the pod gets recreated hopefully it would pull down the latest 65 00:04:29,490 --> 00:04:30,970 version of that image. 66 00:04:31,020 --> 00:04:36,210 And so we could use that as a means to recreate our pods with the latest image or the latest version 67 00:04:36,240 --> 00:04:38,070 of some particular image. 68 00:04:38,070 --> 00:04:39,540 Now why would we not do this. 69 00:04:39,540 --> 00:04:45,980 Well as you might guess deleting pod seems like a really really silly situation or a really silly solution. 70 00:04:46,170 --> 00:04:49,950 There's so many things that could go wrong with this approach in a production environment. 71 00:04:50,040 --> 00:04:54,000 We could very easily accidentally delete the wrong set of pots. 72 00:04:54,000 --> 00:04:55,230 Totally possible. 73 00:04:55,230 --> 00:05:00,400 So if we delete the wrong side of Pod's who knows what type of bad situation we would be in. 74 00:05:00,420 --> 00:05:06,330 In addition if we manually delete all of our Pod's related to one very particular aspect of our application 75 00:05:06,620 --> 00:05:10,630 let's imagine that maybe this is the pod that serves up all of our web traffic. 76 00:05:10,680 --> 00:05:17,580 And so if we delete all those pods for a very brief period of time any user trying to access our application 77 00:05:17,640 --> 00:05:21,440 would be trying to get at a pod or get at a container inside there. 78 00:05:21,540 --> 00:05:25,360 That just doesn't exist in for a very brief window. 79 00:05:25,440 --> 00:05:29,410 Our users would essentially not be able to access our application entirely. 80 00:05:29,520 --> 00:05:33,700 And so everything about deleting these pods just kind of seems like a bad idea. 81 00:05:34,720 --> 00:05:34,930 OK. 82 00:05:34,950 --> 00:05:37,930 So let's take a look at the second possible solution. 83 00:05:37,930 --> 00:05:38,200 All right. 84 00:05:38,200 --> 00:05:45,250 So I want to give you a quick reminder on tagging of darker images when we tag a image we put down usually 85 00:05:45,250 --> 00:05:50,080 our doctor I.D. a slash and then the repository or project name. 86 00:05:50,080 --> 00:05:56,040 Now one other thing that we can optionally put in here is a colon and then a version for this image. 87 00:05:56,040 --> 00:06:00,490 And so we could put in something like you know V-1 and then maybe the next time we build the image we 88 00:06:00,490 --> 00:06:04,980 would increment it to two or three or four or five or whatever it is. 89 00:06:06,010 --> 00:06:12,310 So as a possible solution to this problem we could decide to tag our images with real version numbers 90 00:06:12,550 --> 00:06:16,120 and then specify that version inside the config file. 91 00:06:16,120 --> 00:06:22,690 So in other words when we build our image back over here inside of you know run our doc or build command 92 00:06:22,750 --> 00:06:28,300 and tag the image we could put on a version number like the one V-2 V three or five for whatever it 93 00:06:28,300 --> 00:06:29,110 might be. 94 00:06:30,670 --> 00:06:36,650 We then push that tag to Dharker hub and then inside of our config file we could depend on that. 95 00:06:36,710 --> 00:06:39,620 V v v v 4 or whatever it is. 96 00:06:39,970 --> 00:06:46,030 Now when we change the config file with a version number like this this is an actionable change to our 97 00:06:46,030 --> 00:06:47,020 config file. 98 00:06:47,910 --> 00:06:55,650 So if I put on here V for and then save the file and then rerun that CUV Seitel apply command that is 99 00:06:55,650 --> 00:06:59,530 detected as a very real change to our config file. 100 00:06:59,610 --> 00:07:05,370 And so the config file would be accepted by cube Seitel apply because we are specifying a completely 101 00:07:05,370 --> 00:07:13,180 different image version our deployment would then use that new image version to recreate and update 102 00:07:13,240 --> 00:07:15,000 all of the pause that it manages. 103 00:07:15,010 --> 00:07:17,410 So this would be one possible solution. 104 00:07:17,470 --> 00:07:22,690 Now the downside to this approach is that it really adds an extra step to our deployment process and 105 00:07:22,720 --> 00:07:25,640 it's definitely not a very friendly step. 106 00:07:25,690 --> 00:07:31,330 Let's think about what we would have to do we would essentially have to make sure that any time that 107 00:07:31,330 --> 00:07:36,190 we build our images we would have to spend on some version number over here like you know one two three 108 00:07:36,190 --> 00:07:42,310 four five whatever it is and then we would have to go over to our configuration file and put the exact 109 00:07:42,310 --> 00:07:45,100 same version number inside of your as well. 110 00:07:45,100 --> 00:07:49,760 So we would have to remember the current version and somehow insert that number inside of here. 111 00:07:49,810 --> 00:07:53,440 And that's definitely a non-trivial step to add in here. 112 00:07:53,440 --> 00:07:58,180 Now one quick work around to that that you might imagine if you're you know a little bit savvy you might 113 00:07:58,180 --> 00:08:02,620 think OK well if it's such a pain to get the version number in here maybe we could get like an environment 114 00:08:02,650 --> 00:08:07,410 variable or something like that that would cure the version of that image. 115 00:08:07,450 --> 00:08:12,340 So when we built the image we could store the version number in an environment variable and then reference 116 00:08:12,340 --> 00:08:14,200 that environment variable inside of our file. 117 00:08:14,230 --> 00:08:17,270 So we could do something like you know client version. 118 00:08:17,560 --> 00:08:23,090 Well unfortunately we're not allowed to use environment variables inside of this config files. 119 00:08:23,110 --> 00:08:26,770 So that solution kind of goes out the window as being an easy workaround. 120 00:08:28,150 --> 00:08:33,730 So specifying the version it definitely would work but it adds in that extra step of having to assign 121 00:08:33,760 --> 00:08:34,810 a version number. 122 00:08:34,930 --> 00:08:39,250 When we built the image and then we also have to make sure that we somehow inject that version number 123 00:08:39,310 --> 00:08:40,480 into the file. 124 00:08:40,480 --> 00:08:43,270 We literally would have to inject the version number. 125 00:08:43,310 --> 00:08:45,660 There's some type of like templating process. 126 00:08:45,830 --> 00:08:49,860 So that definitely doesn't seem like it's a very good version or a very good solution as well. 127 00:08:51,030 --> 00:08:58,080 All right so now the last thing we could do is we could use an imperative command to update the image 128 00:08:58,140 --> 00:09:00,610 version that the deployment should use. 129 00:09:00,840 --> 00:09:03,530 So this is somewhat similar to the last step. 130 00:09:03,600 --> 00:09:07,730 It's saying that when we build our image we would still append on a version number. 131 00:09:07,740 --> 00:09:10,840 So like you know v 1 2 3 whatever it is. 132 00:09:11,040 --> 00:09:15,920 But then rather than updating our config file we could immediately run a command. 133 00:09:15,990 --> 00:09:21,990 After building our image that says to Kooper Nettie's essentially like hey Kuber Nettie's like go find 134 00:09:21,990 --> 00:09:27,100 my client deployment and update the version number like you know I don't. 135 00:09:27,110 --> 00:09:30,470 I'm just making up this command here update version to the one. 136 00:09:30,540 --> 00:09:32,210 Or something like that. 137 00:09:32,260 --> 00:09:37,980 Now this is very similar to the previous step in that we are still going to tag our image with a version 138 00:09:37,980 --> 00:09:42,960 number but the downside to this approach is that it's using an imperative command and it's essentially 139 00:09:42,960 --> 00:09:49,080 completely skipping over our config file and keeping our config file uptodate with the state of our 140 00:09:49,080 --> 00:09:50,050 cluster. 141 00:09:50,430 --> 00:09:55,230 So all three these steps seem like you know bad solutions that don't really seem like they're the best 142 00:09:55,230 --> 00:09:57,500 things in the world to solve this problem. 143 00:09:57,540 --> 00:10:01,740 I think without a doubt the first solution over here is definitely very very bad. 144 00:10:02,660 --> 00:10:07,440 I think that the solution right here is definitely a pain in the rear because we are making a change 145 00:10:07,440 --> 00:10:12,350 to our config file and each time that we're changing our config file we would probably want to do a 146 00:10:12,350 --> 00:10:13,480 get commit right. 147 00:10:13,490 --> 00:10:15,660 We would probably want to commit that new version. 148 00:10:15,900 --> 00:10:23,300 Well the downside to wanting to do that it commit is that remember we traditionally only build our versions 149 00:10:23,420 --> 00:10:29,810 with the er build our images with the doc or build the command right here when we are in a see-I environment 150 00:10:29,870 --> 00:10:31,650 like off on Travis s.i. 151 00:10:31,760 --> 00:10:35,470 So we're only on Travis see-I when we've already made a get commit. 152 00:10:35,540 --> 00:10:40,880 So we're kind of talking about like making it get commit to update the image and then pushing this off 153 00:10:40,880 --> 00:10:43,740 to Travis getting the image built right here. 154 00:10:44,000 --> 00:10:49,880 And then simultaneously taking that version number and updating this file and then committing this file 155 00:10:49,880 --> 00:10:52,700 to at the same time while we're still on Travis. 156 00:10:52,700 --> 00:10:54,080 Now that doesn't make sense. 157 00:10:54,080 --> 00:10:55,210 That's really fine. 158 00:10:55,220 --> 00:10:57,140 What I'm trying to say is that this step right here. 159 00:10:57,140 --> 00:11:02,000 It definitely sounds like it's a good solution but in practice it ends up being a tremendous pain in 160 00:11:02,000 --> 00:11:02,820 the rear. 161 00:11:02,840 --> 00:11:06,050 So that kind of leaves us with solution 3 over here. 162 00:11:06,050 --> 00:11:07,880 We're going to use in a period of command. 163 00:11:08,000 --> 00:11:13,730 So after we rebuild an image we are going to tag it with a version number and then we're going to very 164 00:11:13,730 --> 00:11:20,000 specifically reach out to cube CDL and tell it to update our deployment with the latest version of the 165 00:11:20,000 --> 00:11:22,760 image that we just pushed up to darker hub. 166 00:11:23,030 --> 00:11:27,590 Now I know this uses a imperative command and I just told you how we like to avoid these as much as 167 00:11:27,590 --> 00:11:28,240 possible. 168 00:11:28,250 --> 00:11:31,690 But again this is kind of like the best of a bad situation. 169 00:11:31,910 --> 00:11:36,290 And I think that you'll see when we eventually deploy our application to a production environment this 170 00:11:36,290 --> 00:11:39,990 ends up being like a pretty reasonable solution. 171 00:11:40,040 --> 00:11:44,320 Not the best solution but it's pretty reasonable when it really comes down to it. 172 00:11:45,180 --> 00:11:45,860 Oh OK. 173 00:11:45,910 --> 00:11:47,910 So this has been a very long section. 174 00:11:47,920 --> 00:11:52,540 I apologize for the length but again I want to make sure it's really clear that this is just a continuous 175 00:11:53,650 --> 00:11:55,590 not nice issue to have to deal with. 176 00:11:55,600 --> 00:12:00,760 And I want to go over some of these possible solutions because these three in particular get outlined 177 00:12:00,820 --> 00:12:02,080 in this issue thread over here. 178 00:12:02,080 --> 00:12:03,700 If you decide to read this thing. 179 00:12:03,850 --> 00:12:06,610 All right so with all that in mind let's take a quick pause right here. 180 00:12:06,610 --> 00:12:07,940 We're going to come back the next section. 181 00:12:08,020 --> 00:12:12,880 We're going to learn how we can somehow tag our image with a unique version number when we build it 182 00:12:13,780 --> 00:12:16,520 and then make sure that we can run a command. 183 00:12:16,540 --> 00:12:21,690 That's going to tell our deployment to update itself with the latest version number available. 184 00:12:21,700 --> 00:12:23,860 So a quick pause will come back in the next section.