1 00:00:00,001 --> 00:00:01,067 [No Audio] 2 00:00:01,067 --> 00:00:04,134 Till now, we have been revolving around containers 3 00:00:04,134 --> 00:00:07,434 on a single host. Single host would generally mean 4 00:00:07,434 --> 00:00:09,367 one machine or one VM. 5 00:00:10,001 --> 00:00:14,634 They definitely have limited resources and it is totally fine as long 6 00:00:14,634 --> 00:00:16,834 as your purpose is to serve something not so 7 00:00:16,834 --> 00:00:20,934 resource heavy, like a static landing page or a blog. 8 00:00:21,734 --> 00:00:24,201 And one guy would be more than sufficient to 9 00:00:24,201 --> 00:00:27,067 manage it as well. But that's not the only 10 00:00:27,067 --> 00:00:29,234 application why we use containers. 11 00:00:29,234 --> 00:00:32,834 There are giants like Google and PayPal, who have millions 12 00:00:32,834 --> 00:00:36,301 of users a day. In their case, the amount of 13 00:00:36,301 --> 00:00:38,734 containers would be staggeringly high. 14 00:00:38,734 --> 00:00:43,201 And they all may have to communicate in any topology at a 15 00:00:43,201 --> 00:00:46,267 given point of time. In fact, even if we don't 16 00:00:46,267 --> 00:00:49,367 focus on such large applications, a dynamic 17 00:00:49,367 --> 00:00:52,234 website keeping track of visitors and collecting 18 00:00:52,234 --> 00:00:55,467 data from their actions would also need way more 19 00:00:55,467 --> 00:00:57,301 containers than a usual blog. 20 00:00:58,334 --> 00:01:01,067 Let's say even if we did manage to deploy 21 00:01:01,067 --> 00:01:04,134 all of these containers on the same host somehow, 22 00:01:05,001 --> 00:01:10,267 but we might run out of resources any time or due to that the 23 00:01:10,267 --> 00:01:12,867 performance may be affected severely. 24 00:01:12,867 --> 00:01:18,134 Plus, if the host goes down, our site is doomed for sure. 25 00:01:18,767 --> 00:01:20,067 What should we do then? 26 00:01:20,967 --> 00:01:23,867 Well, a simple solution would be, 27 00:01:23,867 --> 00:01:26,901 deploy them on more than one host and get them 28 00:01:26,901 --> 00:01:31,434 managed by more than one DevOps engineers. Sounds fancy. 29 00:01:31,567 --> 00:01:34,534 But they would all be eternally scattered. 30 00:01:34,534 --> 00:01:37,667 And to make sure they remain in sync, we may have 31 00:01:37,667 --> 00:01:40,567 to run another set of micro services in the backend. 32 00:01:40,934 --> 00:01:43,501 Plus, hiring more people for doing the 33 00:01:43,501 --> 00:01:46,467 same task could also be less economic, and none of 34 00:01:46,467 --> 00:01:49,467 the individuals would get opportunities and growth 35 00:01:49,467 --> 00:01:53,067 they deserve. So what to do then? 36 00:01:53,434 --> 00:01:57,267 Well, it seems like we need someone who can make all of these 37 00:01:57,267 --> 00:02:00,501 hosts collaborate, and allow us to manage them 38 00:02:00,501 --> 00:02:03,301 simultaneously from a single instance. 39 00:02:03,701 --> 00:02:05,234 Kind of like cluster, 40 00:02:05,867 --> 00:02:08,767 in fact, exactly like a cluster of 41 00:02:08,767 --> 00:02:12,667 Docker hosts. This way, our containers will be in 42 00:02:12,667 --> 00:02:15,567 sync, their performance won't be reduced due to 43 00:02:15,567 --> 00:02:18,867 resource scarcity. They can be managed from a 44 00:02:18,867 --> 00:02:22,567 single endpoint. We can even think of replicas and 45 00:02:22,567 --> 00:02:26,301 backups of our containers for the cases where one 46 00:02:26,301 --> 00:02:29,067 or some of our hosts may go down. 47 00:02:29,567 --> 00:02:31,201 And life will be happy. 48 00:02:31,767 --> 00:02:33,867 But who is that someone? 49 00:02:35,167 --> 00:02:39,567 A container orchestrator is a tool used to provision, shedule, 50 00:02:39,567 --> 00:02:43,067 and manage containers at large scale over one or 51 00:02:43,067 --> 00:02:45,401 more clusters of multiple hosts. 52 00:02:46,734 --> 00:02:50,567 As we have mentioned before, while Docker Ecosystem has many 53 00:02:50,567 --> 00:02:53,101 offerings, some of them being less significant 54 00:02:53,101 --> 00:02:56,034 than the other ones, it has three major tools, 55 00:02:56,034 --> 00:02:58,301 which should be learned by every container 56 00:02:58,301 --> 00:03:02,034 enthusiast. We have already seen Docker Engine and 57 00:03:02,034 --> 00:03:05,367 Docker Compose. The next stop at our journey of 58 00:03:05,367 --> 00:03:08,167 learning containers is the orchestrator developed 59 00:03:08,167 --> 00:03:11,201 and provided by Docker, called Docker Swarm. 60 00:03:12,001 --> 00:03:15,101 The idea and implementation are pretty simple here. 61 00:03:15,234 --> 00:03:18,134 We take a set of Docker Hosts and connect them 62 00:03:18,167 --> 00:03:21,634 using Swarm Mode. One of these hosts manually 63 00:03:21,634 --> 00:03:24,601 initializes the cluster and becomes the manager of 64 00:03:24,601 --> 00:03:28,234 the cluster. The manager provides a key which can 65 00:03:28,234 --> 00:03:31,234 be used by other nodes to join the cluster. 66 00:03:31,234 --> 00:03:35,201 Once they join the manager, they become worker nodes. 67 00:03:35,201 --> 00:03:38,167 The analogy is pretty self explanatory here. 68 00:03:38,801 --> 00:03:41,901 We as users communicate with the manager and the 69 00:03:41,901 --> 00:03:44,967 manager communicates with the workers, quite like a 70 00:03:44,967 --> 00:03:48,067 management hierarchy of an industry actually. 71 00:03:48,067 --> 00:03:51,567 Just like Docker Compose, we demand our actions in 72 00:03:51,567 --> 00:03:54,867 form of a service, which manager translates into 73 00:03:54,867 --> 00:03:59,867 smaller tasks and provides them to workers to get handled. 74 00:04:00,334 --> 00:04:03,267 To do all of this, manager is equipped 75 00:04:03,267 --> 00:04:07,834 with a set of useful tools such as HTTP API endpoint, 76 00:04:07,834 --> 00:04:10,001 which makes it capable of serving our 77 00:04:10,001 --> 00:04:14,101 service requests and creating objects out of those services. 78 00:04:14,101 --> 00:04:16,634 Orchestrator which passes tasks 79 00:04:16,666 --> 00:04:19,434 translated from services to workers. 80 00:04:19,666 --> 00:04:23,966 Allocator which allocates internal clusters IPs to the 81 00:04:23,966 --> 00:04:25,966 workers and manager itself. 82 00:04:26,534 --> 00:04:31,534 Dispatcher with decides which node will serve which task and gives 83 00:04:31,534 --> 00:04:33,967 this information to the orchestrator. 84 00:04:34,234 --> 00:04:40,167 And finally, Scheduler. The task provided by orchestrator are idle. 85 00:04:40,367 --> 00:04:42,767 They don't run as soon as they get 86 00:04:42,767 --> 00:04:46,501 allocated. Scheduler signals workers to run the 87 00:04:46,501 --> 00:04:49,834 task which they have received and so it also 88 00:04:49,834 --> 00:04:53,234 decides which tasks will run first and which won't. 89 00:04:53,234 --> 00:04:55,367 [No Audio] 90 00:04:55,367 --> 00:04:58,767 As for workers, they're pretty simple compared to manager. 91 00:04:58,901 --> 00:05:01,401 They have two key components in total. 92 00:05:02,034 --> 00:05:05,067 Worker, which connects to the dispatcher of the 93 00:05:05,067 --> 00:05:08,467 master to check if it has any task to receive from 94 00:05:08,467 --> 00:05:12,667 the orchestrator and Executor, which literally does 95 00:05:12,667 --> 00:05:16,434 what its name suggests, it executes the tasks. 96 00:05:16,567 --> 00:05:19,367 Which means it creates containers, volumes 97 00:05:19,401 --> 00:05:22,901 networks and runs them. You may have noticed that 98 00:05:22,901 --> 00:05:25,967 Docker hasn't been the most creative firm, as far 99 00:05:25,967 --> 00:05:29,067 as naming the tools is concerned. Since Swarm is 100 00:05:29,067 --> 00:05:32,467 an orchestrator, which has a component called 101 00:05:32,467 --> 00:05:35,634 orchestrator running on its manager, and worker 102 00:05:35,634 --> 00:05:39,267 has a component called worker. We can't change this, 103 00:05:39,267 --> 00:05:41,101 but we can make sure that we don't get 104 00:05:41,101 --> 00:05:45,001 confused by it. So in this course, whenever we 105 00:05:45,001 --> 00:05:48,301 refer to Orchestrator and Worker, we will indicate 106 00:05:48,301 --> 00:05:51,567 orchestrating tool in general and worker nodes. 107 00:05:51,567 --> 00:05:54,801 If we want to address the internal components instead, 108 00:05:54,801 --> 00:05:57,201 we will call them out specifically. 109 00:05:57,201 --> 00:06:00,634 Just like every other topic, we also have a bunch of 110 00:06:00,634 --> 00:06:03,467 hands-on demos for Swarm. But to understand how 111 00:06:03,467 --> 00:06:05,801 deploying containers on a cluster is different 112 00:06:05,801 --> 00:06:09,567 from deploying them on a single host, take this example. 113 00:06:10,301 --> 00:06:12,567 Let's say we have a service which needs 114 00:06:12,567 --> 00:06:15,401 three replicas of Nginx containers hosting the 115 00:06:15,401 --> 00:06:18,634 same content. Once we provide the service to the 116 00:06:18,634 --> 00:06:21,901 manager, it divides this into three smaller tasks 117 00:06:21,934 --> 00:06:26,034 and allocates one task to each worker. So all of 118 00:06:26,034 --> 00:06:30,534 the workers would be hosting one instance of Nginx web server container. 119 00:06:31,501 --> 00:06:33,834 With that said, by now, you 120 00:06:33,834 --> 00:06:36,701 might even be wondering about what would happen if 121 00:06:36,701 --> 00:06:41,201 Swarm faces failure? In other words, what if one 122 00:06:41,201 --> 00:06:43,267 or more nodes go down? 123 00:06:44,101 --> 00:06:47,067 To know the answer, let's get to the next lecture.