1 00:00:04,210 --> 00:00:10,090 Service updates. You've probably assumed all along that there's some way to update your services even 2 00:00:10,090 --> 00:00:12,080 though we haven't been focusing on that yet. 3 00:00:12,130 --> 00:00:19,090 Let's talk about it because updates has a whole lot of stuff going on under the covers. Swarm's 4 00:00:19,260 --> 00:00:26,140 update functionality is centered around a rolling update pattern for your replicas. Which means if you 5 00:00:26,140 --> 00:00:31,810 have a service with more than one replica, and hopefully you do, it's going to roll through them by default, 6 00:00:32,080 --> 00:00:37,480 one at a time, updating each container by replacing it with the new settings that you're putting in the 7 00:00:37,480 --> 00:00:38,480 update command. 8 00:00:39,460 --> 00:00:44,590 A lot of people will say that orchestrators prevent downtime in updates, but I'm not going to say that 9 00:00:44,590 --> 00:00:45,980 this prevents downtime. 10 00:00:46,000 --> 00:00:53,320 I'm going to say it limits downtime. Because preventing downtime in any system is the job of testing. 11 00:00:53,380 --> 00:01:00,010 You really need to start testing how you do your updates and determining, does it impact my users? 12 00:01:00,010 --> 00:01:05,260 Does updating a database impact my web application? It probably does. 13 00:01:05,260 --> 00:01:10,510 Each application that you have a service for is going to update and impact the other things around it 14 00:01:10,510 --> 00:01:11,450 differently. 15 00:01:11,500 --> 00:01:13,000 That's not the job of an orchestrator. 16 00:01:13,040 --> 00:01:13,330 An 17 00:01:13,340 --> 00:01:19,930 orchestrator can't determine that this one is a database protocol, and this one is a REST application protocol 18 00:01:19,930 --> 00:01:20,890 that's easy. 19 00:01:20,890 --> 00:01:24,550 So those are going to be different, complicated things that you need to deal with. 20 00:01:24,700 --> 00:01:30,820 In the case of service updates, if it's just a REST API or a web frontend that's not doing anything 21 00:01:30,820 --> 00:01:36,700 fancy like web sockets or long polling, if it's something very simple like that or a static website, 22 00:01:37,060 --> 00:01:40,720 you'll probably have an easy update and it won't be a problem. 23 00:01:40,780 --> 00:01:47,070 But other services like databases or persistent storage or anything that requires a persistent connection... 24 00:01:47,230 --> 00:01:50,430 those are always going to be a challenge no matter what you're trying to update. 25 00:01:50,440 --> 00:01:53,180 So test early and test often. 26 00:01:53,380 --> 00:01:58,450 Like I said before, this will definitely replace containers in most updates. Unless you're updating 27 00:01:58,450 --> 00:02:01,910 a label or some other metadata with the service, 28 00:02:02,050 --> 00:02:06,560 it's going to roll through and change out each container with a totally new one. 29 00:02:06,580 --> 00:02:10,500 Just be prepared for that. It has many options. In fact, 30 00:02:10,510 --> 00:02:16,630 the last I counted, there was at least 77 options for the update command. But just about everything you 31 00:02:16,630 --> 00:02:18,400 want to do can be tweaked. 32 00:02:18,400 --> 00:02:24,940 A lot of the options in the update command are actually create options that just have a -rm 33 00:02:24,940 --> 00:02:31,660 and a -add on the end of them. Because if it's an option that can be used for multiple values, 34 00:02:31,660 --> 00:02:37,210 let's say a port to publish or an environment variable, those you can use many of them. 35 00:02:37,240 --> 00:02:37,770 Right? 36 00:02:37,840 --> 00:02:42,860 So, you need to be able to tell the update command which ones you're adding and which ones you're removing. 37 00:02:42,880 --> 00:02:44,620 We'll see those in a minute. 38 00:02:44,620 --> 00:02:47,840 This also includes rollback and health check options. 39 00:02:47,920 --> 00:02:53,320 You should look at the options for those and see if their default values aren't ideal for your application 40 00:02:53,320 --> 00:02:58,370 and test different settings to see if it makes an update easier for you and your system. 41 00:02:59,300 --> 00:03:04,260 You also will see that we have scale and rollback options in here that are their own commands now. 42 00:03:04,280 --> 00:03:10,010 They used to be options that you had to specify with the --rollback or --scale, but so many 43 00:03:10,010 --> 00:03:15,410 people have been using those so frequently that Docker is now making them sort of first class citizens 44 00:03:15,410 --> 00:03:16,420 in the command line. 45 00:03:16,640 --> 00:03:19,020 They might be adding more of those in the future. 46 00:03:20,600 --> 00:03:27,920 Lastly, before we get to some examples, if you're doing stacks, a stack deploy to the same stack is 47 00:03:27,920 --> 00:03:28,820 an update. 48 00:03:28,850 --> 00:03:32,540 In fact, there is no separate option for stack updates. 49 00:03:32,540 --> 00:03:35,850 You just do a stack deploy with the same file that's been edited. 50 00:03:35,870 --> 00:03:40,520 Then, it will work with the service commands and the networks, and every other thing it does. It will 51 00:03:40,520 --> 00:03:44,760 work with them to make sure if any changes are necessary, that they get applied. 52 00:03:44,990 --> 00:03:47,940 Let's look at some quick examples and then we'll get to the command line. 53 00:03:48,910 --> 00:03:54,310 This one is probably the most common example that you'll be using, which is to change the image of a 54 00:03:54,310 --> 00:03:55,000 service. 55 00:03:55,150 --> 00:03:59,260 Every time you update your app and you build a new image, you're going to have to do a service update 56 00:03:59,260 --> 00:04:03,190 command, with the image name, and then the service name. 57 00:04:03,190 --> 00:04:07,750 So in this case, maybe I had my application with a tag of 1.2.0. 58 00:04:07,770 --> 00:04:13,140 And in this case I'm now applying a 1.2.1 image, and the service will determine, 59 00:04:13,180 --> 00:04:16,180 ah yes, that's a different image than I have running in my service, 60 00:04:16,210 --> 00:04:22,400 and we'll go and update them. On this next one, we're showing how you can do multiple things at once inside 61 00:04:22,400 --> 00:04:23,900 a single update command. 62 00:04:23,990 --> 00:04:30,070 You can add an environment variable with the env-add, and then you can remove a port with the publish 63 00:04:30,070 --> 00:04:31,240 -rm. 64 00:04:31,250 --> 00:04:36,650 We could also be adding and removing environment variables and publish ports in the same update command 65 00:04:36,920 --> 00:04:41,840 as much as we want. On this last one, this is showing how we can use these new scale and rollback 66 00:04:41,840 --> 00:04:47,300 commands on multiple services at the same time. Which is one of the advantages of using them over the 67 00:04:47,300 --> 00:04:51,170 update command is that they can apply to multiple services. 68 00:04:51,170 --> 00:04:56,360 In this case, I'm actually going to be changing the number of replicas of the web and the API services 69 00:04:56,360 --> 00:04:57,950 at the same time. 70 00:04:58,010 --> 00:05:03,060 Like I said a while ago, in the Swarm updates, you don't have a different deploy command. 71 00:05:03,140 --> 00:05:08,930 It's just the same docker stack deploy, with the file that you've edited, and it's job is to work with 72 00:05:09,020 --> 00:05:12,590 all of the other parts of the API to determine if there's any changes needed, 73 00:05:12,650 --> 00:05:16,830 and then roll those out with a service update. 74 00:05:16,830 --> 00:05:21,780 All right. Let's start by actually creating a service so that we can manipulate it with some update commands. 75 00:05:22,470 --> 00:05:36,200 docker service create -p 8088 80 name web, and we'll use Nginx, and we're going to specify a version like 76 00:05:36,200 --> 00:05:41,220 we always should in production. 77 00:05:41,250 --> 00:05:49,140 It's nice, now that we actually have in the last half of 2017, the detach option with our service create 78 00:05:49,140 --> 00:05:53,450 and update commands, we can actually see this happen synchronously in real time. 79 00:05:53,460 --> 00:05:59,490 So this will be good for update commands to see how updates actually roll out via the command line. 80 00:05:59,490 --> 00:06:04,800 All right. Now, if we do a docker service ls, we see that our service is running and that it's got 81 00:06:04,800 --> 00:06:08,470 1 of 1 replicas, so it's good to go. 82 00:06:08,470 --> 00:06:15,910 Now let's scale our service up so we can have some more replicas to work with. docker service scale 83 00:06:16,840 --> 00:06:23,110 Web=5. And you just saw that one of those was already running, 84 00:06:23,120 --> 00:06:27,770 and the other 4 had to start. It went by pretty quickly on mine because I already had the image 85 00:06:27,770 --> 00:06:33,170 downloaded, but yours may take a few minutes while they're in pending state as the image downloads on 86 00:06:33,170 --> 00:06:34,190 the other nodes. 87 00:06:35,110 --> 00:06:35,380 All right. 88 00:06:35,380 --> 00:06:40,400 Let's do a rolling update by changing the image of that Nginx. 89 00:06:48,340 --> 00:06:50,510 You'll see here that I've picked an older image. 90 00:06:50,520 --> 00:06:53,850 Now, Docker doesn't care about what the image actually is. 91 00:06:53,850 --> 00:06:55,870 It could be a completely different application 92 00:06:55,980 --> 00:07:00,710 for all it cares. It just knows that in this service, I'm changing it to a different image. 93 00:07:02,190 --> 00:07:06,320 Remember, by default, it's going to go through here one at a time. 94 00:07:06,330 --> 00:07:11,030 It will first remove it, create a new one, and then when that one's good to go, 95 00:07:11,040 --> 00:07:18,010 and it looks healthy, it'll start in the next one. In the next example, we're going to change the published 96 00:07:18,010 --> 00:07:18,740 port. 97 00:07:18,820 --> 00:07:20,520 But you can't change a port. 98 00:07:20,530 --> 00:07:24,060 You actually have to add and remove them at the same time. 99 00:07:24,070 --> 00:07:31,000 So in this case, because we first published it with an 8088, we need to do a docker Service update 100 00:07:33,160 --> 00:07:41,770 publish rm 8088. I don't need to specify the value. I just need to specify the key. Then 101 00:07:41,770 --> 00:07:53,170 we're going to publish the new one, 9090. Then the value, which in this case is 80. You'll see that 102 00:07:53,170 --> 00:07:57,970 it will do the same update process as before. 103 00:07:57,980 --> 00:08:04,850 The last example I want to talk about is kind of a tip. Because you'll often have a challenge with 104 00:08:04,850 --> 00:08:10,010 something called rebalancing. Or if you change the number of nodes or if you move a lot of things around, 105 00:08:10,610 --> 00:08:15,710 if you have a lot of containers in your swarm, you may find that they're not really evened out. You've 106 00:08:15,710 --> 00:08:20,660 got maybe some nodes that are pretty light on how many containers are running and other ones that have 107 00:08:20,660 --> 00:08:27,500 a lot. If you have a lot of things changing, Swarm will not move things around to keep everything balanced 108 00:08:27,500 --> 00:08:30,140 in terms of the number of resources used. 109 00:08:30,200 --> 00:08:38,090 But, what you can do is you can force an update of a service even without changing anything in that service. 110 00:08:38,090 --> 00:08:45,770 Then, it will reissue tasks, and in that case, it will pick the least used nodes, which is a form of rebalancing. 111 00:08:46,040 --> 00:08:52,640 A lot of times in a smaller swarm when I move something big, or add a bunch of nodes, I suddenly have 112 00:08:52,640 --> 00:08:56,310 a bunch of empty servers doing nothing and I need to get work on them. 113 00:08:56,330 --> 00:09:03,800 So what I'll do is take one or two of my services, and I will do a docker service update -- 114 00:09:03,810 --> 00:09:11,080 force, and in this case it's going to roll through and completely replace the tasks. 115 00:09:11,080 --> 00:09:15,670 Of course it will use the schedule's default of looking for nodes with the least number of containers 116 00:09:15,670 --> 00:09:17,830 and the least number of resources used. 117 00:09:18,140 --> 00:09:24,720 That's kind of a trick to get around an uneven amount of work on your nodes. 118 00:09:24,850 --> 00:09:28,180 Remember to clean up by removing the service that we created in this lecture.