1
00:00:05,940 --> 00:00:06,210
‫All right.

2
00:00:06,210 --> 00:00:13,020
‫Wherever you're running your Docker from, we can actually create a single node swarm for our own testing

3
00:00:13,020 --> 00:00:13,830
‫purposes.

4
00:00:13,940 --> 00:00:21,720
‫The way I can tell whether Swarm is on or not, I can just do a docker info and you'll notice Swarm

5
00:00:21,720 --> 00:00:22,460
‫inactive.

6
00:00:22,500 --> 00:00:28,740
‫So we know that Swarm hasn't been enabled here. Again, by default, Docker does not enable any of the Swarm

7
00:00:28,740 --> 00:00:30,650
‫features.

8
00:00:30,660 --> 00:00:40,450
‫I can run a docker swarm init for initialize. That took about a half a second and we're done.

9
00:00:40,450 --> 00:00:45,370
‫What we have now is a single node swarm with all the features and functionality that we get out of the

10
00:00:45,370 --> 00:00:46,060
‫box.

11
00:00:48,740 --> 00:00:52,850
‫So that was probably the shortest demo of this entire course.

12
00:00:53,060 --> 00:00:58,680
‫I mean, what just happened? We typed one command and magic. Wasn't actually any magic.

13
00:00:58,730 --> 00:01:04,790
‫It was a lot of very quick and efficient things in the Go programming of Docker, but essentially, right

14
00:01:04,800 --> 00:01:05,440
‫out of the box,

15
00:01:05,450 --> 00:01:10,700
‫it does a bunch of PKI and security stuff. It creates a root certificate for the swarm that it

16
00:01:10,700 --> 00:01:17,180
‫will use to establish trust and sign certificates for all nodes and all managers. It will create

17
00:01:17,180 --> 00:01:22,280
‫a special certificate for this first manager node because it's a manager versus a worker.

18
00:01:22,280 --> 00:01:29,210
‫Then it creates these tokens that we can actually use on other nodes to join this swarm.

19
00:01:29,340 --> 00:01:35,640
‫Then a bunch of other things in the background where it enables the swarm API and creates something

20
00:01:35,820 --> 00:01:41,270
‫called the Raft Consensus Database, which we'll talk about later in a production part of the course.

21
00:01:41,280 --> 00:01:48,660
‫Just so you know, Raft is a protocol that actually ensures consistency across multiple nodes, and it's

22
00:01:48,660 --> 00:01:54,600
‫ideal for using in the Cloud where we can't guarantee that any one thing will be available for any moment

23
00:01:54,600 --> 00:01:55,530
‫in time.

24
00:01:55,620 --> 00:01:59,970
‫It creates that database on disk. It stores the configuration of the swarm,

25
00:02:00,000 --> 00:02:02,740
‫and that first manager, and it actually encrypts it.

26
00:02:02,760 --> 00:02:08,340
‫Assuming you're on Version 1.13 or newer. Then it will wait for any other nodes before it starts actually

27
00:02:08,340 --> 00:02:10,460
‫replicating the database over to them.

28
00:02:10,530 --> 00:02:15,500
‫Again, all of this traffic that it would be doing once we create other nodes is all going to be encrypted.

29
00:02:15,690 --> 00:02:20,190
‫One of the key components of Swarm that differentiated it when it first came out was that we didn't

30
00:02:20,190 --> 00:02:26,700
‫need an additional key value storage system or some database architecture to be the backend configuration

31
00:02:26,700 --> 00:02:28,720
‫management of our swarm.

32
00:02:28,800 --> 00:02:33,960
‫If you've been around the industry for years or decades even, there is this concept typically of

33
00:02:33,960 --> 00:02:39,870
‫the config db, which is this separate database system that you usually need to make redundant that will

34
00:02:39,870 --> 00:02:45,390
‫store all the information about your orchestration and automation system. Swarm has actually built that

35
00:02:45,390 --> 00:02:50,140
‫straight into Docker right into the daemon and handles it for us.

36
00:02:50,280 --> 00:02:54,990
‫We never really need to do anything. There's no passwords to worry about. There's no special services

37
00:02:54,990 --> 00:02:56,620
‫to start up or anything like that.

38
00:02:58,550 --> 00:03:00,070
‫So, back to the command line.

39
00:03:00,140 --> 00:03:03,960
‫You'll notice here that it talks about...if I want to add a worker to the swarm,

40
00:03:03,980 --> 00:03:07,830
‫I just really need to cut and paste this onto the other servers I would add.

41
00:03:07,850 --> 00:03:12,080
‫Later, we're actually going to build a multi node swarm, but for now, we're just going to keep this

42
00:03:12,080 --> 00:03:15,340
‫at a single node. Let's take a look at a couple of the commands will get out of it.

43
00:03:15,470 --> 00:03:22,400
‫First thing is we can do docker node ls. In this case, we're just seeing the one manager node

44
00:03:22,400 --> 00:03:23,210
‫that we've created.

45
00:03:23,210 --> 00:03:28,550
‫You'll notice it's marked as leader, and there can only be one leader at a time amongst all managers.

46
00:03:28,550 --> 00:03:34,520
‫Again, since we only got one, then obviously it's the leader. We can look at help see what other

47
00:03:34,550 --> 00:03:41,090
‫options we have here. Really, the nodes commands used for bringing your servers in and out of the

48
00:03:41,090 --> 00:03:47,080
‫swarm, or promoting them from workers to managers, or demoting them from managers back down to workers.

49
00:03:47,150 --> 00:03:54,060
‫If you go back the dockers swarm command for a little bit, we'll notice that it actually is a very narrow

50
00:03:54,060 --> 00:03:55,050
‫scope to command.

51
00:03:55,050 --> 00:03:59,050
‫It really is just to initialize, either join or leave.

52
00:03:59,400 --> 00:04:04,200
‫The new unlock command, which we can talk about in a later lecture.

53
00:04:04,200 --> 00:04:08,950
‫For now, let's focus on the exciting new Docker service command.

54
00:04:09,570 --> 00:04:14,430
‫Again, service in a swarm replaces the Docker run.

55
00:04:14,550 --> 00:04:19,530
‫I don't know for a fact, but I really think that this was centered around the idea that we didn't

56
00:04:19,530 --> 00:04:26,010
‫want to break existing Docker run functionality, but Docker run was always built from the ground up

57
00:04:26,070 --> 00:04:27,720
‫as a single host solution.

58
00:04:27,720 --> 00:04:33,090
‫It's whole idea was to focus on local containers on the system that it's talking to. Whereas, when we

59
00:04:33,090 --> 00:04:37,900
‫start talking about a cluster, we don't care so much about individual nodes.

60
00:04:37,920 --> 00:04:42,510
‫We don't actually probably name them. We treat them like cattle, if you've ever heard of the pets

61
00:04:42,510 --> 00:04:45,750
‫versus cattle analogy where they're just a number.

62
00:04:45,750 --> 00:04:50,260
‫We don't really individually go to each node and start up an individual container.

63
00:04:50,280 --> 00:04:56,340
‫We really just throw requirements at the swarm in the form of services and then it will orchestrate

64
00:04:56,370 --> 00:04:59,580
‫how it needs to lay all that out, on which nodes they need to be,

65
00:04:59,640 --> 00:05:03,300
‫and we just know that it's got our back. docker service create

66
00:05:06,310 --> 00:05:10,380
‫is how we give it some new orders. Let's do something really simple.

67
00:05:10,640 --> 00:05:17,870
‫Let's just actually have it start the Alpine image. Then we're going to have the Alpine image just

68
00:05:17,870 --> 00:05:24,920
‫use ping to hit 8.8.8.8, which is actually a Google DNS server, but we really just want to give it something

69
00:05:24,920 --> 00:05:26,960
‫to do while we investigate what happens.

70
00:05:28,210 --> 00:05:34,360
‫Then you'll see like docker run, it spits back an ID, only that's not the container ID. That's actually

71
00:05:34,360 --> 00:05:36,400
‫the service ID.

72
00:05:37,060 --> 00:05:42,100
‫You'll see that we now have one service listed. Just like with our docker run command, since we didn't

73
00:05:42,100 --> 00:05:42,780
‫name it,

74
00:05:42,790 --> 00:05:47,410
‫it gave it a random name. We can see that it's actually already spun up.

75
00:05:47,410 --> 00:05:52,810
‫The one of one. When you're looking at services, you're always going to see this number with a /

76
00:05:52,810 --> 00:05:57,260
‫in the middle. That represents the one on the left is how many are actually running.

77
00:05:57,340 --> 00:06:00,970
‫And the one on the right is how many you've specified for it to run.

78
00:06:00,970 --> 00:06:05,630
‫The goal of the orchestrator is to make these numbers match, whatever that takes.

79
00:06:05,860 --> 00:06:08,530
‫But this again doesn't actually show us the real container.

80
00:06:08,530 --> 00:06:14,240
‫This is really just showing us a list of our services, so we can drill down a little farther.

81
00:06:14,800 --> 00:06:21,580
‫We do a docker service ps, and then we give it the name or the ID of the service, and that will

82
00:06:21,580 --> 00:06:27,700
‫actually show us the tasks or containers for this service. You'll see that it's similar to the docker

83
00:06:27,730 --> 00:06:33,040
‫container ls command, but it actually has now this node component because when you're dealing with multi servers

84
00:06:33,210 --> 00:06:38,560
‫scenarios, we might need to know which server it's actually running on. You'll notice that it actually gave

85
00:06:38,560 --> 00:06:42,430
‫it a name of an increment on the service name.

86
00:06:42,430 --> 00:06:47,290
‫If we went back to the docker container ls command, that still works.

87
00:06:47,530 --> 00:06:55,060
‫In this case, the orchestration of Swarm is actually adding some information to the names and to the

88
00:06:55,060 --> 00:07:00,150
‫actual images that are running. We'll cover some of those subtle differences later as well.

89
00:07:00,150 --> 00:07:07,050
‫For now, let's actually take that service and let's scale it up. For that, we use the docker service update,

90
00:07:07,200 --> 00:07:14,700
‫and then the name of our service, or the ID in this case, I'll do the ID. And I want to change an attribute

91
00:07:14,760 --> 00:07:16,140
‫about the service.

92
00:07:16,170 --> 00:07:20,730
‫In this case, I want to change the number of replicas.

93
00:07:21,000 --> 00:07:30,120
‫So if we do a docker service ls again, we now see three of three. If we do a docker service ps,

94
00:07:31,520 --> 00:07:36,810
‫we actually now see three tasks. You'll notice that two were just created seconds ago.

95
00:07:36,830 --> 00:07:42,510
‫If we were fast enough, and if we were deploying something big enough, we could actually run the service

96
00:07:42,560 --> 00:07:46,740
‫ls and actually see it show us zero of three. One of three.

97
00:07:46,770 --> 00:07:51,860
‫It'll actually increment as things start up. It just so happens that Alpine was already on this machine,

98
00:07:51,860 --> 00:07:55,250
‫in terms of its image, and it didn't take very long to start up a ping command.

99
00:07:55,250 --> 00:07:57,620
‫We just couldn't be that fast.

100
00:07:57,620 --> 00:08:02,350
‫What's interesting about that update command is that you can imagine the difference between the

101
00:08:02,360 --> 00:08:07,460
‫Docker run command that you might use on a single dev or test server or on your local machine, and the

102
00:08:07,460 --> 00:08:10,400
‫production concerns of always keeping something available

103
00:08:10,430 --> 00:08:11,540
‫as much as possible.

104
00:08:11,600 --> 00:08:16,690
‫That's one of the design goals of Swarm. That command that we actually haven't used yet is the Docker

105
00:08:16,700 --> 00:08:22,520
‫update command. That was a command for the Docker run containers that allowed us to update certain

106
00:08:22,520 --> 00:08:26,660
‫variables on our running container without having to kill it and restart it.

107
00:08:26,840 --> 00:08:33,650
‫Almost all of those options are related to limiting and controlling resource usage for that container.

108
00:08:33,770 --> 00:08:38,480
‫Because that's one of the typical things that you see when you're running a long term application is

109
00:08:38,480 --> 00:08:44,730
‫that you need to change its resources maybe because the databases have gotten bigger and need more RAM.

110
00:08:44,750 --> 00:08:49,720
‫Or maybe you have an out of control process that's eating up too much CPU and you need to limit it.

111
00:08:49,790 --> 00:08:58,700
‫If we do a help on the docker service update command, you'll see that we have a lot more options.

112
00:08:59,300 --> 00:09:06,710
‫Because the goal of a Swarm service is that it's able to replace containers and update changes in the

113
00:09:06,710 --> 00:09:09,890
‫service without taking the entire thing down.

114
00:09:09,890 --> 00:09:16,760
‫If you had a service with three containers in it, you could technically take down one at a time to

115
00:09:16,760 --> 00:09:22,610
‫make a change and do sort of a rolling update, which is the blue green pattern we talked about. That's

116
00:09:22,610 --> 00:09:28,150
‫why we see a lot more options here is because we can change these options that may require a container

117
00:09:28,160 --> 00:09:34,370
‫restart, but the swarm will intelligently make sure that the way we update them is in a pattern that

118
00:09:34,370 --> 00:09:36,530
‫ensures consistent availability.

119
00:09:39,590 --> 00:09:47,270
‫So back to our docker container list real quick. You'll notice that we have these three now, and what if

120
00:09:47,360 --> 00:09:57,560
‫I went in and, sort of as a rogue, did a docker container rm, and I specified one of these containers, and

121
00:09:57,560 --> 00:10:04,030
‫I forced it...let's say I beat the first one and just take it out.

122
00:10:04,250 --> 00:10:04,880
‫All right.

123
00:10:04,910 --> 00:10:10,160
‫Now I do a docker service ls, and you see how it shows two of three?

124
00:10:10,370 --> 00:10:15,870
‫Because I went in behind the back of Swarm and I actually took away a running container,

125
00:10:16,010 --> 00:10:21,470
‫it's going to identify that and it's going to launch a new one within seconds to replace the one that

126
00:10:21,470 --> 00:10:22,180
‫went down.

127
00:10:22,280 --> 00:10:32,630
‫So if I did a docker service ps on frosty, you'll see that it actually shows the history of the

128
00:10:32,660 --> 00:10:39,130
‫first task here in the list is that it had one that failed and it started a new one 24 seconds ago.

129
00:10:39,470 --> 00:10:45,170
‫This is one of the responsibilities of a container orchestration system is to make sure that the

130
00:10:45,170 --> 00:10:48,130
‫services you specified are always running,

131
00:10:48,140 --> 00:10:54,230
‫and if they fail, it recovers from that failure. Which is way different than docker run, right? docker run would

132
00:10:54,230 --> 00:10:56,540
‫never recreate a container.

133
00:10:56,540 --> 00:11:02,120
‫So that's why whenever we do any of these Docker service commands, we're not actually speaking directly

134
00:11:02,120 --> 00:11:05,160
‫to an action like create a container.

135
00:11:05,270 --> 00:11:09,970
‫We're actually telling an orchestration system, hey put this job in your queue.

136
00:11:10,100 --> 00:11:16,610
‫When you can get to it, please perform the actions on the swarm that I've asked here. That's a

137
00:11:16,610 --> 00:11:17,850
‫big difference.

138
00:11:17,900 --> 00:11:22,580
‫It's subtle in the command line, but it's a big difference because it means that there's rollback possibilities.

139
00:11:22,670 --> 00:11:27,230
‫There's failure mitigation and a lot of intelligence built into that.

140
00:11:27,230 --> 00:11:29,990
‫In this case, if I actually wanted to remove all these containers,

141
00:11:29,990 --> 00:11:34,020
‫I'd have to remove the service. I'd have to do docker service rm.

142
00:11:34,130 --> 00:11:35,740
‫And then the frosty.

143
00:11:35,790 --> 00:11:40,130
‫If we do a docker service ls, we see nothing. If we do a docker container

144
00:11:40,130 --> 00:11:43,490
‫ls, we see three containers.

145
00:11:43,860 --> 00:11:45,730
‫Oh and there we go.

146
00:11:45,800 --> 00:11:49,750
‫That shows right there the automation happening on the backend.

147
00:11:49,760 --> 00:11:55,370
‫We were able to quickly show that we deleted the service, but the orchestration system hadn't gone through

148
00:11:55,430 --> 00:12:02,580
‫all of its processes of cleaning up the service and the task behind it. These concepts should be pretty

149
00:12:02,580 --> 00:12:07,710
‫easy to understand because they're just really expanding on the Docker run concepts that we've had earlier

150
00:12:07,710 --> 00:12:08,670
‫in this course.

151
00:12:08,670 --> 00:12:15,030
‫Next let's actually build a multi node swarm and start scaling our containers out.