WEBVTT 1 00:00:00.040 --> 00:00:03.040 I want you to imagine the sheer, oh, the hair 2 00:00:03.120 --> 00:00:05.919 pulling frustration of trying to install a new piece of 3 00:00:05.960 --> 00:00:07.080 software on your computer. 4 00:00:07.240 --> 00:00:08.919 Oh yeah, we've all been there, right. 5 00:00:09.599 --> 00:00:12.560 You find this incredible new tool, you click download, and 6 00:00:12.599 --> 00:00:17.000 then boom, the nightmare sequence begins. The software abruptly halts 7 00:00:17.160 --> 00:00:20.519 and tells you it needs like three other foundational programs 8 00:00:20.559 --> 00:00:20.920 to run. 9 00:00:20.960 --> 00:00:22.559 So you go hunt those down. 10 00:00:22.440 --> 00:00:23.559 And it never just ends there. 11 00:00:23.679 --> 00:00:27.000 No, it never does, because wait, one of those programs 12 00:00:27.120 --> 00:00:30.359 requires a highly specific older version of a library that 13 00:00:30.399 --> 00:00:34.200 you actually already have installed, just a newer version. So 14 00:00:34.240 --> 00:00:36.880 you grit your teeth downgrade the library to satisfy this 15 00:00:36.960 --> 00:00:39.840 one tool, and suddenly half the other applications on your 16 00:00:39.880 --> 00:00:43.920 computer instantly stop working. It is just a domino effect 17 00:00:44.039 --> 00:00:45.200 of digital chaos. 18 00:00:45.320 --> 00:00:48.159 Yeah, I mean, it's the classic Stata dependency. Hell, you 19 00:00:48.200 --> 00:00:50.880 find yourself in a situation where you're spending significantly more 20 00:00:50.880 --> 00:00:56.560 time managing the fragile, air connected logistics of your software 21 00:00:56.719 --> 00:01:00.000 that you are actually using the software to accomplish your goals. 22 00:01:00.799 --> 00:01:04.799 Well, welcome to your new favorite deep dive. Today, we 23 00:01:04.840 --> 00:01:08.519 are pulling excerpts from Jeff Nikoloff's brilliant book Docker in action. 24 00:01:09.000 --> 00:01:11.439 Our mission today is to dissect how a tool called 25 00:01:11.480 --> 00:01:15.599 Docker completely revolutionized the way the entire world builds ships 26 00:01:15.640 --> 00:01:19.519 and runs software. It took the chaotic, brittle process we 27 00:01:19.680 --> 00:01:24.280 just described and transformed it into a streamlined, logistical masterpiece. 28 00:01:24.319 --> 00:01:26.840 And the best part, we are going to explore how 29 00:01:26.879 --> 00:01:29.400 you can use this exact concept to keep your own 30 00:01:29.439 --> 00:01:31.040 computer incredibly tidy. 31 00:01:31.519 --> 00:01:33.920 Yeah, and I think it's important note that while terms 32 00:01:34.000 --> 00:01:37.159 like Docker or Linux containers might sound intimidating to anyone 33 00:01:37.159 --> 00:01:40.920 who doesn't spend their entire day managing massive server farms, 34 00:01:41.560 --> 00:01:44.640 the core concept at play here is remarkably elegant. 35 00:01:44.680 --> 00:01:45.319 It really is. 36 00:01:45.400 --> 00:01:47.799 It solves problems that every single person who uses a 37 00:01:47.799 --> 00:01:50.599 computer is experienced, regardless of their technical background. 38 00:01:50.799 --> 00:01:52.959 So for the duration of this deep dive, I invite 39 00:01:52.959 --> 00:01:54.920 you to step away from the dense code and the 40 00:01:54.959 --> 00:01:59.439 intimidating jargon. We are going into a clear, relatable exploration 41 00:01:59.519 --> 00:02:03.000 of containers and how they basically hand you superpowers over 42 00:02:03.079 --> 00:02:03.920 your own machine. 43 00:02:04.200 --> 00:02:08.199 Yeah. To truly appreciate the magnitude of what Docker accomplished, though, 44 00:02:08.520 --> 00:02:11.560 we first need to understand the agonizing environment it was 45 00:02:11.599 --> 00:02:12.280 built to cure. 46 00:02:12.439 --> 00:02:13.919 Okay, set the stage for us. 47 00:02:14.039 --> 00:02:17.000 So let's examine the author of our source material, Jeff Nikoloff. 48 00:02:18.000 --> 00:02:21.719 In twenty eleven, Jeff was working at Amazon, and at 49 00:02:21.719 --> 00:02:25.000 Amazon he was witnessing what was at the time the 50 00:02:25.080 --> 00:02:27.759 pinnacle of automated infrastructure. 51 00:02:27.319 --> 00:02:31.120 Right because he was watching massive automated rolling deployments, like 52 00:02:31.120 --> 00:02:34.759 they were pushing complex software updates to hundreds of machines 53 00:02:34.800 --> 00:02:37.800 distributed all over the globe, and the entire process was 54 00:02:37.840 --> 00:02:39.199 taking minutes exactly. 55 00:02:39.240 --> 00:02:42.319 The system was handling the dependencies, the routing, the checks. 56 00:02:42.599 --> 00:02:43.439 It was seamless. 57 00:02:43.719 --> 00:02:46.039 And he notes what a stark contrast this was to 58 00:02:46.080 --> 00:02:50.039 his previous jobs, where a software deployment was this ten 59 00:02:50.120 --> 00:02:53.879 hour quarterly slog that usually involved a war room, copious 60 00:02:53.919 --> 00:02:56.439 amounts of coffee, and just praying that nothing in the 61 00:02:56.479 --> 00:02:57.520 legacy system broke. 62 00:02:57.639 --> 00:02:59.840 Yeah, he had seen the mountaintop, right, he knew its 63 00:03:00.000 --> 00:03:03.800 seamless automated software delivery looked like. But then we flash 64 00:03:03.840 --> 00:03:05.240 forward to twenty thirteen. 65 00:03:05.080 --> 00:03:06.520 The reality check totally. 66 00:03:07.080 --> 00:03:10.479 He's at home, sitting at his personal desk trying to 67 00:03:10.520 --> 00:03:14.479 install a relatively simple open source metrics collection and graphic 68 00:03:14.479 --> 00:03:16.479 cool called Graphite. 69 00:03:16.120 --> 00:03:19.360 And this seemingly simple task absolutely breaks him. 70 00:03:19.400 --> 00:03:20.520 Oh it destroys his weekend. 71 00:03:20.840 --> 00:03:24.039 He sits down expecting a quick install, but the provided 72 00:03:24.080 --> 00:03:27.719 instructions are murky at best. He loses hours battling through 73 00:03:27.840 --> 00:03:33.479 undocumented Python dependencies. He's digging into configuration files, manually tweaking 74 00:03:33.479 --> 00:03:37.439 his system paths, downloading random patches, just desperately trying to 75 00:03:37.479 --> 00:03:41.599 get this one single graphic tool to compile and run. Finally, 76 00:03:41.639 --> 00:03:44.199 out of sheer exhaustion, he just throws in the towel. 77 00:03:44.439 --> 00:03:47.319 And you know that failure to install the software was frustrating, 78 00:03:47.599 --> 00:03:50.800 But the real nightmare was the collateral damage. Oh right, 79 00:03:50.879 --> 00:03:54.439 Because in his desperate, multi hour attempt to get Graphite running, 80 00:03:54.759 --> 00:03:58.599 he had altered his computer's underlying environment so drastically it 81 00:03:58.680 --> 00:04:01.319 was now incompatible with the software he used for his 82 00:04:01.400 --> 00:04:02.479 actual day to day work. 83 00:04:02.639 --> 00:04:03.080 Yikes. 84 00:04:03.400 --> 00:04:06.759 Yeah, simply reverting those desperate changes and getting his machine 85 00:04:06.759 --> 00:04:10.120 back to a functional baseline took them an embarrassingly long time. 86 00:04:10.360 --> 00:04:12.840 Okay, let's unpack this because I think everyone listening has 87 00:04:12.879 --> 00:04:16.839 experienced their own flavor of this disaster. I like to 88 00:04:16.879 --> 00:04:20.639 compare a traditional computer's file system to a literal junk 89 00:04:20.720 --> 00:04:21.879 drawer in your kitchen. 90 00:04:21.920 --> 00:04:22.920 Oh I like that right? 91 00:04:23.399 --> 00:04:26.560 When you install traditional software. It's like throwing a handful 92 00:04:26.600 --> 00:04:30.040 of loose tools into that drawer, and the tiny parts 93 00:04:30.040 --> 00:04:33.199 of those tools, the screws, the extension cords, the specialized 94 00:04:33.240 --> 00:04:37.720 batteries which represent our software dependencies and libraries, they get 95 00:04:38.079 --> 00:04:39.360 hopelessly tangled up. 96 00:04:39.240 --> 00:04:39.959 With everything else. 97 00:04:40.000 --> 00:04:41.240 They're just loose in the drawer. 98 00:04:41.399 --> 00:04:44.480 Exactly when you try to pull out a single screwdriver, 99 00:04:45.000 --> 00:04:48.199 you inevitably drag out a tangled mess of wires and 100 00:04:48.240 --> 00:04:51.040 paper clips with it. If you try to delete an app, 101 00:04:51.120 --> 00:04:53.879 are you really getting all the hidden dependencies? If you 102 00:04:53.959 --> 00:04:56.439 upgrade one application, does it snap a wire that another 103 00:04:56.480 --> 00:04:59.839 application was relying on? It is a permanent mess. 104 00:05:00.079 --> 00:05:04.079 Fascinating Here is how docer solves that exact junk drawer 105 00:05:04.120 --> 00:05:09.439 problem through absolute, uncompromising isolation. Well, a few months after 106 00:05:09.480 --> 00:05:13.279 that terrible Graphite experience, Jeff decided to give docer a try. 107 00:05:13.920 --> 00:05:17.319 He navigated to the Docker index, found a pre configured 108 00:05:17.399 --> 00:05:20.720 version of Graphite that another developer had already assembled, and 109 00:05:20.839 --> 00:05:23.399 downloaded it. In less than a minute, he had a 110 00:05:23.439 --> 00:05:28.000 fully configured, flawless Graphite server running on his local machine. 111 00:05:28.040 --> 00:05:31.480 What took him hours of cascading failure before now took 112 00:05:31.560 --> 00:05:35.360 seconds Wow. And the magic was that Docker isolated the 113 00:05:35.399 --> 00:05:39.519 application and all of those messy conflicting dependencies into a 114 00:05:39.600 --> 00:05:43.199 self contained unit called a container. None of those Python 115 00:05:43.279 --> 00:05:45.240 libraries ever actually touched his main. 116 00:05:45.160 --> 00:05:48.519 System, so the junk drawer is permanently fixed. The new 117 00:05:48.560 --> 00:05:52.360 tool is placed inside its own, perfectly sealed, impenetrable box, 118 00:05:52.759 --> 00:05:53.600 and then placed in. 119 00:05:53.560 --> 00:05:56.720 The drawer precisely the mechanic at play. If two different 120 00:05:56.720 --> 00:06:01.240 applications require entirely different, conflicting versions of the same background library, 121 00:06:01.360 --> 00:06:03.600 they don't fight over it, they don't overwrite each other. 122 00:06:03.639 --> 00:06:05.519 They just stay in their boxes exactly. 123 00:06:05.720 --> 00:06:08.959 They each possess their own distinct copy, neatly sealed inside 124 00:06:09.000 --> 00:06:13.519 their respective containers. Your main operating system remains completely pristine. 125 00:06:13.720 --> 00:06:18.199 Okay, But if this technology is so fundamentally life changing 126 00:06:18.720 --> 00:06:22.879 and so completely rewrites how computers handle software, how did 127 00:06:22.879 --> 00:06:26.040 it actually enter the mainstream. You'd think something this revolutionary 128 00:06:26.079 --> 00:06:29.000 would have been on the front page of every major newspaper, 129 00:06:29.560 --> 00:06:32.759 but it sort of infiltrated the tech world quietly. 130 00:06:33.040 --> 00:06:36.079 Yeah. Its introduction to the global stage was actually through 131 00:06:36.360 --> 00:06:41.199 one of the most impactful yet hilariously brief stage presentations 132 00:06:41.240 --> 00:06:42.480 in modern tech history. 133 00:06:42.560 --> 00:06:44.000 Oh the Pyicon presentation. 134 00:06:44.160 --> 00:06:47.319 Yeah. In twenty thirteen, at a developer conference called Pyicon, 135 00:06:47.480 --> 00:06:51.160 the creator of Docker, Solomon Hikes, unveil the technology in 136 00:06:51.199 --> 00:06:55.199 a lightning talk titled the Future of Linux Containers. 137 00:06:54.839 --> 00:06:56.759 And if I remember the source correctly, he didn't even 138 00:06:56.759 --> 00:06:58.959 get to finish the pitch. He was literally cut off 139 00:06:58.959 --> 00:07:01.360 at the five minute mark by the organizers because they 140 00:07:01.360 --> 00:07:04.079 were strictly enforcing the time limits for the segment. 141 00:07:04.160 --> 00:07:06.879 Yeah, the organizers cut his mic. Yeah, But honestly, those 142 00:07:06.920 --> 00:07:09.839 five minutes of demonstration were all it took. Developers in 143 00:07:09.879 --> 00:07:12.519 the room saw the command line interface, they watched the 144 00:07:12.560 --> 00:07:16.160 instantaneous isolation of the software, and they instantly grasped the 145 00:07:16.160 --> 00:07:16.920 paradigm shift. 146 00:07:16.959 --> 00:07:18.000 It just clicked right. 147 00:07:18.360 --> 00:07:21.879 But as with any massive technological leap, there was a 148 00:07:21.920 --> 00:07:25.759 wave of immediate confusion. And the biggest misconception, one that 149 00:07:25.839 --> 00:07:29.959 remarkably persists even today, is the assumption that a Docker 150 00:07:30.000 --> 00:07:33.000 container is just a virtual machine by a different name. 151 00:07:33.120 --> 00:07:35.759 Wait a minute, you just finished telling me that docer 152 00:07:35.839 --> 00:07:39.439 isolates software in its own, completely secure environment so it 153 00:07:39.480 --> 00:07:41.279 doesn't mess with the rest of the host computer. 154 00:07:41.560 --> 00:07:42.240 Yeah. 155 00:07:42.480 --> 00:07:45.160 I know enough about tech to know that is exactly 156 00:07:45.199 --> 00:07:47.839 what a virtual machine does. Are you telling me Docker 157 00:07:47.920 --> 00:07:51.160 is actually fundamentally different or just a better branded virtual mission? 158 00:07:51.279 --> 00:07:55.279 Oh? They are architecturally worlds apart, and for running individual 159 00:07:55.360 --> 00:07:59.680 pieces of software, Docker is vastly more efficient. Consider the 160 00:07:59.720 --> 00:08:03.120 macae annex of a virtual machine. Okay, hardware virtualization requires 161 00:08:03.120 --> 00:08:06.959 your computer to literally simulate an entire second computer. In software, 162 00:08:07.439 --> 00:08:10.120 you have to run a massive, redundant operating system, a 163 00:08:10.199 --> 00:08:13.279 complete guest os on top of your main operating system 164 00:08:13.600 --> 00:08:14.759 just to run one application. 165 00:08:14.959 --> 00:08:15.319 Oh whoy. 166 00:08:15.399 --> 00:08:18.399 Yeah, it consumes massive amounts of RAMCPU cycles and it 167 00:08:18.439 --> 00:08:20.800 takes minutes just to boot up the fake computer. 168 00:08:21.120 --> 00:08:24.279 Oh, I see the distinction. So running a virtual machine 169 00:08:24.480 --> 00:08:27.680 is like building an entire replica of a house in 170 00:08:27.720 --> 00:08:31.839 your backyard, complete with its own concrete foundation, its own plumbing, 171 00:08:32.039 --> 00:08:35.159 and its own electrical grid, just because you want a 172 00:08:35.200 --> 00:08:37.320 new kitchen to cook one specific meal. 173 00:08:37.759 --> 00:08:41.240 That is a very apt way to visualize the resource waste. 174 00:08:41.600 --> 00:08:43.679 So if a VM is building a whole new house, 175 00:08:43.759 --> 00:08:45.399 what is a Docker container doing. 176 00:08:45.639 --> 00:08:48.519 A Docker container is simply upgrading the kitchen inside your 177 00:08:48.519 --> 00:08:49.159 existing house. 178 00:08:49.240 --> 00:08:49.960 Huh. 179 00:08:50.039 --> 00:08:53.320 You're utilizing the exact same foundation, the same plumbing, and 180 00:08:53.360 --> 00:08:57.279 the same electrical grid, which in computing terms. Is the 181 00:08:57.320 --> 00:09:02.840 host computer's Linux kernels running inside Docker containers interface directly 182 00:09:02.879 --> 00:09:06.440 with the existing operating system using two specific features built 183 00:09:06.440 --> 00:09:09.039 into Linux, name spaces and C groups. 184 00:09:09.200 --> 00:09:10.919 Name spaces and c groups, right. 185 00:09:11.000 --> 00:09:13.440 And notably, those features have existed in Linux since two 186 00:09:13.440 --> 00:09:16.759 thousand and seven. Docer didn't invent the underlying technology, It 187 00:09:16.840 --> 00:09:18.200 just made it incredibly accessible. 188 00:09:18.240 --> 00:09:20.600 Okay, let me guess how those work. Name spaces give 189 00:09:20.600 --> 00:09:24.080 the container specific name and C groups group the files together. 190 00:09:25.440 --> 00:09:29.039 Not quite. Think of name spaces as the opaque concrete 191 00:09:29.080 --> 00:09:32.200 walls of the literal cell. They stop the application from 192 00:09:32.279 --> 00:09:36.440 seeing or touching any other processes, networks, or filesystems outside 193 00:09:36.480 --> 00:09:40.320 its box. The application truly believes it is entirely alone 194 00:09:40.360 --> 00:09:43.639 in the universe. In crystal groups control groups, they act 195 00:09:43.679 --> 00:09:46.600 as the warden of that cell. They dictate exactly how 196 00:09:46.679 --> 00:09:50.480 much of the computer's physical resources like CPU cycles in RAM, 197 00:09:50.919 --> 00:09:53.879 that specific isolated prisoner is allowed. 198 00:09:53.600 --> 00:09:56.559 To consume, so it can't just take over exactly. 199 00:09:56.240 --> 00:09:58.879 Ensuring it can never hog the entire server and crash 200 00:09:58.879 --> 00:10:01.840 the host machine. Because of this direct relationship with the kernel, 201 00:10:02.399 --> 00:10:05.519 zero resources are wasted simulating virtual hardware. 202 00:10:05.559 --> 00:10:08.240 Wait a second, hold on the source material explicitly mentions 203 00:10:08.279 --> 00:10:10.879 that Docker relies on the Linux kernel. It does what 204 00:10:10.960 --> 00:10:13.840 if you or I or the listener are running a 205 00:10:13.879 --> 00:10:16.399 Mac or a Windows machine, we don't have a Linux 206 00:10:16.480 --> 00:10:19.240 kernel for the container to share. You just spent five 207 00:10:19.320 --> 00:10:23.360 minutes bashing virtual machines for being massive, bloated resource hogs, 208 00:10:23.600 --> 00:10:25.559 and now you're telling me that anyone not running a 209 00:10:25.600 --> 00:10:29.320 Linux has to use one anyway. How does that solve anything. 210 00:10:29.559 --> 00:10:32.240 I feel like the house analogy just collapsed. I hear 211 00:10:32.240 --> 00:10:35.159 the skepticism, and it's a very common pushback, but the 212 00:10:35.279 --> 00:10:39.360 architecture actually holds up brilliantly. Okay, explain on Mac in Windows. 213 00:10:39.759 --> 00:10:42.960 Docker does indeed utilize a virtual machine in the background, 214 00:10:43.759 --> 00:10:46.720 But the crucial distinction is in the quantity and the scale. 215 00:10:47.159 --> 00:10:51.720 It spins up exactly one single, highly optimized, lightweight virtual 216 00:10:51.759 --> 00:10:55.720 machine just to run the Linux kernel. Just one, just one. 217 00:10:55.840 --> 00:10:58.840 Then all of your hundreds of Docker containers run on 218 00:10:58.879 --> 00:10:59.960 top of that single vm. 219 00:11:00.320 --> 00:11:00.799 Ah. 220 00:11:01.480 --> 00:11:04.360 So instead of spinning up ten massive virtual machines to 221 00:11:04.440 --> 00:11:09.000 run ten apps, I have one tiny, invisible virtual machine 222 00:11:09.320 --> 00:11:11.240 hosting ten lightweight containers. 223 00:11:11.320 --> 00:11:15.080 Precisely, the resource overhead is fixed and minimal. You still 224 00:11:15.120 --> 00:11:15.840 cure the bloat. 225 00:11:16.080 --> 00:11:19.720 Okay, to really grasp how these lightweight, self contained kitchens 226 00:11:19.720 --> 00:11:22.200 are delivered to your computer, we have to examine the 227 00:11:22.279 --> 00:11:25.720 name itself Docker. It's a very deliberate word choice by 228 00:11:25.720 --> 00:11:26.279 the creators. 229 00:11:26.480 --> 00:11:29.480 Yeah, the entire ecosystem relies heavily on the metaphor of 230 00:11:29.559 --> 00:11:33.799 global physical shipping logistics. Before the invention of the standardized 231 00:11:33.799 --> 00:11:37.519 steel shipping container, loading cargo onto a ship was a 232 00:11:37.600 --> 00:11:38.600 logistical nightmare. 233 00:11:38.679 --> 00:11:39.679 Right, I've seen pictures of that. 234 00:11:39.960 --> 00:11:43.840 You had barrels of oil, sacks of grain, wood, and creates, 235 00:11:43.840 --> 00:11:47.360 some machinery, all different shapes, all different sizes, all requiring 236 00:11:47.399 --> 00:11:51.120 specialized handling by stevedoors. A ship could spend weeks just 237 00:11:51.440 --> 00:11:53.440 sitting in a port being loaded. 238 00:11:53.279 --> 00:11:57.360 Which sounds exactly like installing software manually. You have one 239 00:11:57.399 --> 00:12:01.360 program that requires a highly specialized sequel daybase, another that 240 00:12:01.399 --> 00:12:05.480 requires a specific Python environment, and a third that demands 241 00:12:05.519 --> 00:12:11.519 a custom network port configuration. Every installation requires custom manual labor. 242 00:12:12.080 --> 00:12:15.200 Then the physical shipping industry standardized on the corrugated steel 243 00:12:15.240 --> 00:12:18.879 shipping container. Suddenly the contents became irrelevant to the. 244 00:12:18.799 --> 00:12:20.480 Logistics because it's all just in a box. 245 00:12:20.679 --> 00:12:23.120 Right, It didn't matter if you were shipping luxury cars, 246 00:12:23.240 --> 00:12:27.000 frozen fish, or electronics. Because everything was locked inside a 247 00:12:27.039 --> 00:12:30.000 standard steel box, the exact same dock side cranes, the 248 00:12:30.039 --> 00:12:33.320 same trucks, and the same ships could handle it universally. 249 00:12:33.399 --> 00:12:34.720 And Docker did that for code. 250 00:12:34.879 --> 00:12:38.840 Docker accomplished the exact same miracle for software. The process 251 00:12:38.840 --> 00:12:42.399 of pulling and running software with Docker is identical, no 252 00:12:42.440 --> 00:12:46.039 matter how incredibly complex. The software inside the container is 253 00:12:46.799 --> 00:12:48.840 the crane that picks it up, which is the Docker 254 00:12:48.840 --> 00:12:52.559 command line, uses the exact same motion every single time. 255 00:12:52.720 --> 00:12:56.159 Here's where it gets really interesting, because inside that ecosystem, 256 00:12:56.440 --> 00:13:01.000 the book highlights a crucial, often misunderstood distinction between an 257 00:13:01.039 --> 00:13:02.240 image and a container. 258 00:13:02.519 --> 00:13:05.440 Yeah, those terms are frequently used interchangeably by those new 259 00:13:05.480 --> 00:13:09.120 to the technology, but they represent entirely different states. An 260 00:13:09.159 --> 00:13:13.519 image is the bundled, shippable snapshot. It's the rigid blueprint. 261 00:13:13.840 --> 00:13:17.120 It contains the application code, the libraries, the system tools, 262 00:13:17.159 --> 00:13:20.240 the dependencies, everything frozen perfectly in time. 263 00:13:20.320 --> 00:13:23.879 So the image is the literal cargo packed tightly inside 264 00:13:23.919 --> 00:13:26.960 the steel box, sitting on the dock, ready to be shipped. 265 00:13:26.679 --> 00:13:29.519 Exactly, and a container is the actual running instance of 266 00:13:29.600 --> 00:13:32.159 that image. You download the image, and when you execute 267 00:13:32.159 --> 00:13:36.039 a command, Docker creates a living, breathing container from that static. 268 00:13:35.799 --> 00:13:37.360 Blueprint, so you can make copies. 269 00:13:37.720 --> 00:13:41.080 And the beauty is you can spawn as many identical 270 00:13:41.080 --> 00:13:45.039 containers as you want from a single image. These images 271 00:13:45.080 --> 00:13:48.679 are the universal shivable units, and they are shared globally 272 00:13:49.159 --> 00:13:51.879 through a massive public port called Docker Hub. 273 00:13:52.000 --> 00:13:54.000 It's mind blowing when you step back and look at it. 274 00:13:54.080 --> 00:13:57.320 Docker essentially did for complex computer servers what the app 275 00:13:57.320 --> 00:13:58.519 Store did for smartphones. 276 00:13:58.759 --> 00:13:59.279 You really did. 277 00:13:59.440 --> 00:14:04.440 It created this universal, standardized, frictionless way to package and 278 00:14:04.440 --> 00:14:07.759 distribute software. You just point and click or in this case, 279 00:14:07.919 --> 00:14:10.360 type a single unified command and it just works. 280 00:14:10.639 --> 00:14:14.200 If we connect this to the bigger picture, the implications 281 00:14:14.240 --> 00:14:18.360 for portability are staggering. Because the image includes every single 282 00:14:18.399 --> 00:14:21.879 obscure dependency it needs to run, and it interfaces directly 283 00:14:21.919 --> 00:14:25.240 with the standardized kernel. It means you, the listener, can 284 00:14:25.320 --> 00:14:28.240 run the exact same software on your personal weekend laptop 285 00:14:28.559 --> 00:14:31.039 that a massive tech giant is running in their billion 286 00:14:31.080 --> 00:14:32.679 dollar cloud data center. 287 00:14:32.799 --> 00:14:33.279 That's wild. 288 00:14:33.320 --> 00:14:36.960 There are zero compatibility issues. The notorious developer excuse of 289 00:14:37.000 --> 00:14:40.159 well it worked on my machine essentially disappears overnight because 290 00:14:40.200 --> 00:14:43.279 the environment inside the container is identical everywhere on Earth. 291 00:14:43.440 --> 00:14:48.480 And because these containers are perfectly sealed, opaque boxes, they 292 00:14:48.519 --> 00:14:52.679 don't just solve logistics and portability, they solve a massive 293 00:14:52.919 --> 00:14:54.600 glaring problem with security. 294 00:14:54.960 --> 00:14:57.600 Yeah, let's trace the history of the container concept back 295 00:14:57.639 --> 00:15:01.080 a bit further. Long before the term cont was popularized, 296 00:15:01.440 --> 00:15:06.039 historical UNAX style operating systems referred to this isolation technique 297 00:15:06.159 --> 00:15:10.039 as a jail. A jail, Yeah, The terminology dates all 298 00:15:10.080 --> 00:15:12.600 the way back to Sun Microsystems selerais ten in two 299 00:15:12.600 --> 00:15:16.080 thousand and five. The fundamental goal was to create a 300 00:15:16.120 --> 00:15:20.200 modified runtime environment that strictly prevents a program from accessing 301 00:15:20.279 --> 00:15:21.679 protected host resources. 302 00:15:21.759 --> 00:15:22.320 A jail. 303 00:15:22.360 --> 00:15:25.120 I actually love that. It's a very visceral, descriptive way 304 00:15:25.159 --> 00:15:26.200 to think about software. 305 00:15:26.279 --> 00:15:28.759 It paints the perfect picture, right YEA. A container severely 306 00:15:28.799 --> 00:15:31.600 limits the scope of a potential disaster. When you run 307 00:15:31.600 --> 00:15:35.000 a program normally on your computer, it often has terrifyingly 308 00:15:35.039 --> 00:15:38.480 broad access to your entire file system, your network interfaces, 309 00:15:38.519 --> 00:15:42.000 your memory. But inside a doctor container, thanks to those 310 00:15:42.080 --> 00:15:45.919 name spaces we discussed, a program can only access what 311 00:15:46.039 --> 00:15:50.519 is explicitly manually allowed by you. It restricts process IDs, 312 00:15:50.720 --> 00:15:53.000 meaning the container can't even per see that other programs 313 00:15:53.039 --> 00:15:56.080 are running on the computer. It restricts network access, it 314 00:15:56.159 --> 00:15:57.440 isolates shared memory. 315 00:15:58.000 --> 00:15:59.879 Okay, let me push the limits of this jail cell. 316 00:16:00.279 --> 00:16:03.799 If a hacker manages to compromise a web application I'm running, 317 00:16:04.200 --> 00:16:07.000 or if I deliberately download a piece of sketchy software 318 00:16:07.000 --> 00:16:09.120 from a dark corner of the Internet and run it 319 00:16:09.159 --> 00:16:11.919 inside a Docker container, does that mean I am one 320 00:16:12.039 --> 00:16:14.799 hundred percent of youn am I completely safe to run 321 00:16:14.879 --> 00:16:15.960 viruses just for fun. 322 00:16:16.080 --> 00:16:18.080 I have to stop you right there, because that is 323 00:16:18.120 --> 00:16:21.879 a dangerous assumption. Aw Man Docker provides a crucial defense 324 00:16:21.919 --> 00:16:25.480 in depth strategy, but it is not impenetrable magic. You 325 00:16:25.519 --> 00:16:29.879 should never blindly run untrusted software, particularly if you are 326 00:16:29.919 --> 00:16:33.279 configuring that container to require administrative privileges or mapping it 327 00:16:33.320 --> 00:16:34.679 to your main personal. 328 00:16:34.440 --> 00:16:37.000 Filesystem so the walls of the jail cell can be broken. 329 00:16:37.360 --> 00:16:41.519 Remember, the containers share the host's underlying kernel. While escaping 330 00:16:41.559 --> 00:16:46.840 a properly configured container is exceedingly difficult, it is not mathematically. 331 00:16:46.279 --> 00:16:49.320 Impossible, especially if I mess up the settings. 332 00:16:49.000 --> 00:16:52.320 Exactly, if the host system itself is misconfigured, or if 333 00:16:52.360 --> 00:16:58.399 you the user accidentally granted the container elevated root privileges. However, 334 00:16:59.000 --> 00:17:02.440 comparing it to install owing that same sketchy software directly 335 00:17:02.480 --> 00:17:07.319 onto your unprotected hard drive, it massively astronomically reduces your 336 00:17:07.400 --> 00:17:08.079 risk surface. 337 00:17:08.279 --> 00:17:08.960 That makes sense. 338 00:17:09.119 --> 00:17:12.319 If a traditional web server gets hacked, the attacker likely 339 00:17:12.359 --> 00:17:15.880 gains full access to your entire operating system. If a 340 00:17:15.920 --> 00:17:20.839 containerized webserver gets hacked, the attacker is by default trapped 341 00:17:20.880 --> 00:17:24.880 staring at the blank, isolated walls of that specific container's 342 00:17:24.920 --> 00:17:25.839 empty jail cell. 343 00:17:26.200 --> 00:17:28.880 So if these name spaces and cre groups are creating 344 00:17:28.920 --> 00:17:32.599 a literal secure jail cell around the application, how do 345 00:17:32.640 --> 00:17:34.559 you actually get the software into the cell in the 346 00:17:34.599 --> 00:17:36.920 first place without breaking the isolation. Let's look at the 347 00:17:36.920 --> 00:17:37.559 command line. 348 00:17:37.680 --> 00:17:41.640 Yeah, even for complex infrastructure, Docker reduces the initial deployment 349 00:17:41.640 --> 00:17:43.559 to the classic Hello world syntax. 350 00:17:43.680 --> 00:17:44.640 Okay, walk me through it. 351 00:17:44.839 --> 00:17:48.720 If you open your terminal and type Docker run Docker inaction, 352 00:17:48.839 --> 00:17:49.759 Hello world. 353 00:17:50.359 --> 00:17:52.400 Let me visualize this. I hit enter. 354 00:17:52.839 --> 00:17:55.880 My computer obviously knows it doesn't have that specific file yet. 355 00:17:56.400 --> 00:17:59.640 Is it acting like a basic web browser just instantly 356 00:17:59.640 --> 00:18:03.000 fetch a text script from a URL and dumping the 357 00:18:03.039 --> 00:18:04.160 output into my terminal. 358 00:18:04.240 --> 00:18:07.400 It's far more sophisticated than a simple script fetch. There 359 00:18:07.480 --> 00:18:11.880 is an entire invisible orchestration happening. First, the Docker demon 360 00:18:11.920 --> 00:18:14.440 which is the background logistics manager running on your computer, 361 00:18:14.880 --> 00:18:16.559 checks your local hard drive. 362 00:18:16.559 --> 00:18:18.079 To see if I already have it right. 363 00:18:18.480 --> 00:18:22.200 It asks, do I already possess the blueprint the image 364 00:18:22.599 --> 00:18:24.640 for hell a World? If this is your first time? 365 00:18:24.720 --> 00:18:27.519 The answer is no, So it automatically reaches out and 366 00:18:27.599 --> 00:18:29.400 queries Docker Hub on the Internet. 367 00:18:29.480 --> 00:18:31.920 It locates the specific ship and container sitting at the 368 00:18:31.960 --> 00:18:32.559 global port. 369 00:18:32.720 --> 00:18:36.559 Correct, it downloads the image. Then it uses that blueprint 370 00:18:36.640 --> 00:18:38.559 to forge a brand new container, and it starts the 371 00:18:38.559 --> 00:18:42.640 program inside. The isolated program simply prints the words hello 372 00:18:42.680 --> 00:18:45.480 World to your screen, and having completed its only task, 373 00:18:45.799 --> 00:18:49.119 the program exits. And then what and here is a 374 00:18:49.200 --> 00:18:54.039 vital concept. The running state of a container is inextricably 375 00:18:54.079 --> 00:18:56.759 tied to the state of the main process inside it. 376 00:18:57.480 --> 00:19:00.640 Because the program finished its job and stopped, the container 377 00:19:00.680 --> 00:19:01.880 immediately stops running. 378 00:19:01.880 --> 00:19:04.400 Two. Wait, so if I hit the up arrow and 379 00:19:04.519 --> 00:19:07.240 run that exact same command a second time, I'm not 380 00:19:07.319 --> 00:19:10.119 restarting the app I just downloaded. I'm actually spawning a 381 00:19:10.160 --> 00:19:11.480 perfect sterile clone of it. 382 00:19:11.680 --> 00:19:15.079 The mechanism there is exactly right because you issued the 383 00:19:15.119 --> 00:19:18.359 run command again. The demon checks locally sees that you 384 00:19:18.400 --> 00:19:21.039 now possess the downloaded image, so it skips the network 385 00:19:21.079 --> 00:19:24.640 download entirely, but it builds a brand new, completely separate, 386 00:19:24.640 --> 00:19:26.480 second container and executes it. 387 00:19:26.599 --> 00:19:27.079 Oh wow. 388 00:19:27.079 --> 00:19:29.759 This reis is an important question about logistics, though. How 389 00:19:29.799 --> 00:19:32.279 do you manage all those invisible boxes you keep spawning? 390 00:19:32.359 --> 00:19:33.799 Yeah, because they just pile up. 391 00:19:33.920 --> 00:19:36.400 Exactly if you run that command ten times, you now 392 00:19:36.440 --> 00:19:39.559 have ten stopped dead containers just sitting invisible on your 393 00:19:39.559 --> 00:19:42.680 hard drive. Knowing how to start a container dictates that 394 00:19:42.759 --> 00:19:44.440 you must also learn how to list them and clean 395 00:19:44.480 --> 00:19:44.759 them up. 396 00:19:44.839 --> 00:19:46.400 Get it enter the trash right. 397 00:19:46.680 --> 00:19:49.720 The command doctor help is vital for learning tools like 398 00:19:49.799 --> 00:19:53.519 Docker paps to view your active instances or Dogger pem 399 00:19:53.559 --> 00:19:55.160 to permanently sweep away the old ones. 400 00:19:55.319 --> 00:19:58.319 But a program that prints Hello World and immediately dies 401 00:19:58.400 --> 00:20:01.480