WEBVTT 1 00:00:00.120 --> 00:00:05.200 Imagine buying like a beautifully crafted, fully furnished house, but 2 00:00:05.320 --> 00:00:07.679 to move that house to a new city, you have 3 00:00:07.719 --> 00:00:09.279 to tear it down to the studs. 4 00:00:09.480 --> 00:00:11.320 Yeah, pack all the lumbers. 5 00:00:11.039 --> 00:00:14.519 Get rugs exactly, drive across the country, and rebuild the 6 00:00:14.679 --> 00:00:18.160 entire structure from memory, just hoping the plumbing is still. 7 00:00:17.920 --> 00:00:20.760 Align which you know it almost never does, right. 8 00:00:20.679 --> 00:00:23.719 But for decades, that is essentially how we deployed software. 9 00:00:23.920 --> 00:00:27.079 You'd build this pristine application on your laptop, ship the 10 00:00:27.120 --> 00:00:30.640 code over to a production server, and suddenly, boom, everything 11 00:00:30.679 --> 00:00:32.640 breaks because the environment is slightly different. 12 00:00:32.679 --> 00:00:34.159 It's the classic developer nightmare. 13 00:00:34.240 --> 00:00:37.600 Totally. Well, today we are looking at the technology that 14 00:00:37.679 --> 00:00:40.280 took that fragile house and turned it into a standardized 15 00:00:40.320 --> 00:00:44.439 shipping container. We are giving you a shortcut to understanding Docker. 16 00:00:44.640 --> 00:00:46.920 It's such a massive shift in how things work. 17 00:00:47.119 --> 00:00:51.679 It really is. So whether you're prepping for a DevOps meeting, 18 00:00:52.000 --> 00:00:54.640 optimizing your own deployment workflow, or you just want to 19 00:00:54.640 --> 00:00:58.200 fully grasp the mechanics of how the modern web actually runs, 20 00:00:58.600 --> 00:01:00.000 We're going to clear up the mystery for you. 21 00:01:00.439 --> 00:01:03.439 And our roadmap today comes from a highly practical source. 22 00:01:03.679 --> 00:01:06.840 It's an ebook published by Packed publishing called What You 23 00:01:06.879 --> 00:01:09.280 Need to Know About Docker by Scott Gallagher. 24 00:01:09.439 --> 00:01:10.560 Yeah, it's a great read. 25 00:01:10.799 --> 00:01:13.519 It really cuts through the noise and provides just a 26 00:01:13.719 --> 00:01:18.920 brilliant distillation of the absolute essentials of containerization. 27 00:01:19.599 --> 00:01:22.239 And our mission for this deep dive is to extract 28 00:01:22.400 --> 00:01:26.159 those exact essentials. We're going to explore the underlying architecture 29 00:01:26.159 --> 00:01:28.920 of a container, how you can build and manipulate these 30 00:01:28.920 --> 00:01:33.280 systems yourself, and know how to navigate the sprawling Docker 31 00:01:33.400 --> 00:01:34.359 ecosystem that. 32 00:01:34.480 --> 00:01:36.519 Orchestrates it all because it is brawling. 33 00:01:36.640 --> 00:01:39.760 Oh absolutely, but by the end you'll have that deeply 34 00:01:39.799 --> 00:01:45.120 satisfying aha moment regarding modern infrastructure. Okay, let's unpack this. 35 00:01:45.200 --> 00:01:45.680 Let's do it. 36 00:01:45.760 --> 00:01:48.359 Before we get into typing out code and executing commands, 37 00:01:48.359 --> 00:01:50.599 we have to look at the critical bottleneck Docker was 38 00:01:50.640 --> 00:01:53.560 actually trying to solve. I mean, why did this specific 39 00:01:53.680 --> 00:01:58.000 tool see such explosive industry altering adoption. 40 00:01:58.599 --> 00:02:01.319 Well, to understand the adoption option rate, we really need 41 00:02:01.359 --> 00:02:03.599 to go back to twenty thirteen to a company called 42 00:02:03.680 --> 00:02:04.280 dot Cloud. 43 00:02:04.319 --> 00:02:06.239 Dot cloud right, Yeah. 44 00:02:06.000 --> 00:02:09.240 They operated in the platform as a service space, meaning 45 00:02:09.560 --> 00:02:13.520 their entire business model relied on spinning up server environments 46 00:02:13.520 --> 00:02:15.120 for their clients at scale. 47 00:02:14.919 --> 00:02:16.919 Right, they had to do it constantly. 48 00:02:16.560 --> 00:02:20.439 Exactly, but they hit a severe structural limitation, which was 49 00:02:20.560 --> 00:02:23.800 virtual machines spinning up a new VM every time a 50 00:02:23.840 --> 00:02:29.240 client needed an environment was frankly, agonizingly slow and incredibly 51 00:02:29.280 --> 00:02:33.919 resource heavy. So to drastically decrease their startup times, doc 52 00:02:33.960 --> 00:02:38.159 cloud turned to the concept of containers. Docker was literally 53 00:02:38.199 --> 00:02:41.960 born out of this desperate engineering need for speed and efficiency. 54 00:02:42.080 --> 00:02:45.240 And it's not like Docker just invented containerization out of 55 00:02:45.240 --> 00:02:47.280 thin air in twenty thirteen, right, Like the pieces were 56 00:02:47.319 --> 00:02:48.120 already on the board. 57 00:02:48.159 --> 00:02:48.800 Oh, exactly. 58 00:02:48.919 --> 00:02:52.120 What's fascinating here is that the foundational mechanics were already 59 00:02:52.120 --> 00:02:55.759 built into the Linux ecosystem, just waiting to be utilized cohesively. 60 00:02:56.319 --> 00:02:56.759 Okay, yeah. 61 00:02:56.800 --> 00:03:00.719 Docer originally relied on Linux containers commonly known as LA, 62 00:03:00.919 --> 00:03:03.439 and these containers are built on two critical features within 63 00:03:03.520 --> 00:03:04.280 the Linux kernel. 64 00:03:04.319 --> 00:03:05.280 Break those down for us. 65 00:03:05.400 --> 00:03:08.039 Sure, So, first you have name spaces, which vide the 66 00:03:08.080 --> 00:03:11.840 illusion of isolation. Name spaces ensure that a process only 67 00:03:11.879 --> 00:03:16.280 sees its own specific files, network ports, and process IDs. 68 00:03:16.080 --> 00:03:18.599 So it basically thinks it's completely alone on the machine. 69 00:03:18.759 --> 00:03:21.560 Precisely, it has no idea that things are running. And 70 00:03:21.639 --> 00:03:24.879 second you have c groups or control groups. This was 71 00:03:24.879 --> 00:03:27.159 a feature introduced way back in August two thousand and 72 00:03:27.199 --> 00:03:30.240 eight in kernel version two point six point twenty four. 73 00:03:30.319 --> 00:03:32.159 Wow, so quite a bit earlier. 74 00:03:32.280 --> 00:03:32.800 Yeah. 75 00:03:32.960 --> 00:03:37.000 And while name spaces isolate visibility, CE groups isolate resources, 76 00:03:37.240 --> 00:03:39.680 they put a strict cap on how much CPU or 77 00:03:39.759 --> 00:03:43.719 memory that specific collection of processes is allowed to consume. 78 00:03:44.000 --> 00:03:46.639 I see. So the genius of Docker wasn't creating the 79 00:03:46.680 --> 00:03:50.400 container concept from scratch. It was engineering a management damon 80 00:03:50.479 --> 00:03:53.199 and an API that made deploying these C groups and 81 00:03:53.280 --> 00:03:55.840 name spaces universal and highly portable. 82 00:03:55.879 --> 00:03:56.800 You get the nail on the head. 83 00:03:57.039 --> 00:03:59.159 You know. The virtual machine comparison is crucial here, and 84 00:03:59.199 --> 00:04:01.520 I think looking at the architecture side by side really 85 00:04:01.560 --> 00:04:02.639 clarifies the mechanism. 86 00:04:02.719 --> 00:04:04.000 It's the best way to visualize it. 87 00:04:04.319 --> 00:04:07.840 Yeah, think about running a traditional virtual machine like buying 88 00:04:07.879 --> 00:04:10.960 an empty plot of land. Every single time you want 89 00:04:11.000 --> 00:04:12.639 to run a new application, you have to pour a 90 00:04:12.639 --> 00:04:17.600 new foundation, build a separate house, and install completely independent 91 00:04:17.720 --> 00:04:19.600 plumbing and electrical systems. 92 00:04:19.199 --> 00:04:21.920 From scratch, which is exhausting even to think about. 93 00:04:22.120 --> 00:04:25.920 Exactly in the server world, that means installing a hypervisor. 94 00:04:26.240 --> 00:04:29.480 Then installing a heavy host operating system and then installing 95 00:04:29.519 --> 00:04:33.040 another vast heavy guest operating system, like you know, a 96 00:04:33.040 --> 00:04:36.959 full two gigabyte version of red hat or Debian just to. 97 00:04:36.959 --> 00:04:40.240 Run a single ten megabyte application. Right, It's wild, an 98 00:04:40.399 --> 00:04:44.279 enormous duplication of effort. You're allocating RAM and CPU cycles 99 00:04:44.480 --> 00:04:47.560 just to keep redundant operating systems idling in the background. 100 00:04:47.600 --> 00:04:51.160 But a Docker container changes the architecture entirely. Using docer 101 00:04:51.279 --> 00:04:53.439 is like renting an apartment in a high rise building. 102 00:04:53.560 --> 00:04:54.480 I love this analogy. 103 00:04:54.600 --> 00:04:57.480 Thanks. Yeah, all the apartments in that building share the 104 00:04:57.560 --> 00:05:01.639 exact same underlying plumbing electrical foundation, which in our case 105 00:05:02.000 --> 00:05:07.120 is the host machine's single Linux kernel. But your specific apartment, 106 00:05:07.240 --> 00:05:10.439 your isolated namespace, is completely locked off from your neighbors. 107 00:05:10.519 --> 00:05:13.920 And the practical result of sharing that kernel is just staggering. 108 00:05:14.519 --> 00:05:17.120 Because a Docker container doesn't require you to boot up 109 00:05:17.120 --> 00:05:20.319 a separate guest operating system every single time. These containers 110 00:05:20.360 --> 00:05:22.199 are incredibly lightweight. 111 00:05:22.120 --> 00:05:23.319 Like how lightweight are we talking? 112 00:05:23.439 --> 00:05:27.519 We're talking megabytes instead of gigabytes. Furthermore, because there is 113 00:05:27.560 --> 00:05:31.600 no OS boot sequence, they start up in milliseconds. That's insane, 114 00:05:31.879 --> 00:05:34.920 it is. And because they package the application with all 115 00:05:34.959 --> 00:05:39.000 of its specific dependencies, the exact libraries, the exact binaries. 116 00:05:39.480 --> 00:05:44.079 They guarantee consistency, meaning you can build a container on 117 00:05:44.199 --> 00:05:47.240 a local Windows laptop, hand it over to a production 118 00:05:47.360 --> 00:05:50.639 server running Linux in the cloud, and it will execute identically. 119 00:05:50.839 --> 00:05:53.720 So the notorious well it works on my machine excuse 120 00:05:53.879 --> 00:05:57.839 is officially dead, dead and buried. Good riddance. Now we've 121 00:05:57.879 --> 00:06:01.959 successfully isolated the application in theory. But you know, theory 122 00:06:02.000 --> 00:06:04.800 doesn't deploy code. How do we actually get our hands 123 00:06:04.800 --> 00:06:05.680 on these containers? 124 00:06:06.000 --> 00:06:08.720 The journey usually starts at the Docker Hub. Think of 125 00:06:08.759 --> 00:06:12.600 the Docker hub as a centralized registry specifically for infrastructure 126 00:06:12.600 --> 00:06:13.360 and environments. 127 00:06:13.439 --> 00:06:15.639 Okay, like an app store for servers. 128 00:06:15.240 --> 00:06:15.879 Pretty much. 129 00:06:16.519 --> 00:06:19.439 If you open your command line and type Docker search Aubuntu, 130 00:06:19.879 --> 00:06:22.920 the registry will return a list of available images. What 131 00:06:23.079 --> 00:06:26.639 kind of images you'll see official repositories maintained by canonical 132 00:06:27.000 --> 00:06:31.240 automated builds, and specialized images created by the community. Once 133 00:06:31.279 --> 00:06:34.480 you find what you need, you execute docker pole followed 134 00:06:34.519 --> 00:06:38.639 by the repository name, like Docker pole a Buntu dot Latest, 135 00:06:39.040 --> 00:06:42.439 and the demon downloads that image directly to your local machine. 136 00:06:42.480 --> 00:06:44.720 Wait, hold on a second. If millions of developers all 137 00:06:44.720 --> 00:06:46.639 over the world are pulling down in a Buntu Dot 138 00:06:46.720 --> 00:06:49.839 latest image and maybe pulling older versions like a Buntu 139 00:06:49.879 --> 00:06:52.680 Dot warrant Team point zero four. How does the local 140 00:06:52.759 --> 00:06:55.800 machine keep track of all these different operating system files 141 00:06:56.040 --> 00:06:58.680 without just overwriting everything into a giant mess? 142 00:06:58.800 --> 00:07:02.079 That is a great question. Docer handles casing and storage 143 00:07:02.439 --> 00:07:06.360 through a very clever cryptographic system. It tracks everything using 144 00:07:06.360 --> 00:07:07.040 an image ID. 145 00:07:07.279 --> 00:07:08.040 Then image ID. 146 00:07:08.199 --> 00:07:08.720 Yeah, it's a. 147 00:07:08.800 --> 00:07:12.959 Unique sixty four character hexadecimal string generated by hashing the 148 00:07:13.000 --> 00:07:14.160 contents of the image. 149 00:07:14.279 --> 00:07:17.959 Okay, but a sixty four character scring is basically impossible 150 00:07:17.959 --> 00:07:19.319 for a human departse. 151 00:07:19.120 --> 00:07:22.360 Exactly, which is why Docker smartly shortens it to just 152 00:07:22.399 --> 00:07:24.800 the first twelve digits when you run at commands like 153 00:07:24.839 --> 00:07:28.360 Docker images. So under the hood, the system doesn't just 154 00:07:28.399 --> 00:07:31.720 see the word Ubuntu, right, it sees a hyper specific 155 00:07:31.720 --> 00:07:35.160 Alpha America identifier tied to the exact state of those files. 156 00:07:35.600 --> 00:07:38.160 You can have dozens of different versions of a system 157 00:07:38.199 --> 00:07:41.279 cashed on your drive, and because their hashes differ, their 158 00:07:41.319 --> 00:07:43.240 file pads remain entirely distinct. 159 00:07:43.439 --> 00:07:44.519 They will never collide. 160 00:07:44.639 --> 00:07:46.839 Oh wow, that is incredibly elegant. 161 00:07:46.920 --> 00:07:47.480 It really is. 162 00:07:47.639 --> 00:07:49.680 So we've pulled our image and it's sitting on our 163 00:07:49.720 --> 00:07:52.720 hard drive. But an image is just a static template, right, 164 00:07:52.759 --> 00:07:53.639 it's a snapshot. 165 00:07:53.720 --> 00:07:54.079 Correct. 166 00:07:54.120 --> 00:07:56.399 To actually use it, we have to turn that static 167 00:07:56.439 --> 00:07:59.040 image into a running container process. 168 00:07:59.199 --> 00:08:02.480 And the fundamental can man for that transformation is Docker run. 169 00:08:02.800 --> 00:08:06.720 But the specific flags you pass dictate how that process behaves. 170 00:08:06.759 --> 00:08:07.519 Give us an example. 171 00:08:07.639 --> 00:08:08.360 Sure, if you. 172 00:08:08.279 --> 00:08:10.279 Want to jump inside the container and look around and 173 00:08:10.360 --> 00:08:12.959 maybe test a shell script or check a directory structure, 174 00:08:13.439 --> 00:08:14.519 you'd use the flags. 175 00:08:14.240 --> 00:08:15.680 In what does that stand for? 176 00:08:16.000 --> 00:08:18.800 Interactive in NITTI, it gives you a pseudo terminal directly 177 00:08:18.839 --> 00:08:20.720 connected to the container's standard input. 178 00:08:20.879 --> 00:08:21.800 Ah, gotcha. 179 00:08:21.959 --> 00:08:24.240 On the other hand, if you are deploying a web 180 00:08:24.279 --> 00:08:27.439 server or a database that just needs to operate silently, 181 00:08:27.879 --> 00:08:31.160 you'd use the ud flag for demon mode. It detaches 182 00:08:31.199 --> 00:08:32.840 the container and runs it in the background. 183 00:08:33.240 --> 00:08:36.240 Okay, and you can monitor those detached processes anytime by 184 00:08:36.240 --> 00:08:39.399 typing Docker It tapes right yep exactly, which outputs a 185 00:08:39.440 --> 00:08:42.879 list of all your active containers, their specific image IDs, 186 00:08:43.000 --> 00:08:47.039 the ports they're exposing. And I love this part. The 187 00:08:47.279 --> 00:08:50.320 random usually pretty funny names. Docker assigns them if you 188 00:08:50.399 --> 00:08:52.080 don't explicitly name them yourself. 189 00:08:52.159 --> 00:08:53.799 Yeah, the naming generator is great, but. 190 00:08:53.799 --> 00:08:56.240 Eventually we have to shut these background processes down. 191 00:08:57.000 --> 00:09:00.720 This raises an important question regarding process management, because there 192 00:09:00.759 --> 00:09:03.679 is a severe difference between stopping a container and killing 193 00:09:03.679 --> 00:09:04.240 a container. 194 00:09:04.440 --> 00:09:06.559 Oh sounds dramatic. 195 00:09:06.480 --> 00:09:06.960 It can be. 196 00:09:07.519 --> 00:09:11.039 You have two primary commands at your disposal, Docker kill 197 00:09:11.159 --> 00:09:13.639 and Docker stop. If you are just testing something locally 198 00:09:13.639 --> 00:09:16.559 and you want the container gone immediately, docer kill sends 199 00:09:16.600 --> 00:09:18.679 a sig kill signal to the process, so. 200 00:09:18.600 --> 00:09:20.360 It just drops the ax instantly. 201 00:09:20.399 --> 00:09:21.159 It's determination. 202 00:09:21.799 --> 00:09:24.200 But if you are working in a production environment, you 203 00:09:24.240 --> 00:09:25.759 should always use Docker stopped. 204 00:09:25.799 --> 00:09:29.639 Oh really, So if I use the wrong command to 205 00:09:29.639 --> 00:09:31.879 shut down my container on a Friday afternoon, I could 206 00:09:31.960 --> 00:09:36.440 inadvertently corrupt the company's entire production database. That's terrifying. 207 00:09:36.639 --> 00:09:39.840 It is entirely possible if you use kill yakes. Yeah, 208 00:09:40.200 --> 00:09:42.960 when you use Docker stop, the demon sends a sig 209 00:09:43.039 --> 00:09:47.000 term signal first. This affords the application of grace period 210 00:09:47.480 --> 00:09:50.480 usually about ten seconds, allowing it to finish its current 211 00:09:50.519 --> 00:09:54.600 read write operations, flush its memory caches, and close its 212 00:09:54.639 --> 00:09:56.000 database connections properly. 213 00:09:56.120 --> 00:09:56.919 Oh, that makes sense. 214 00:09:57.080 --> 00:09:59.559 Only after that grace period does it send the kill signal, 215 00:10:00.519 --> 00:10:03.200 relying on Docker kill in a live environment is basically 216 00:10:03.279 --> 00:10:05.879 playing Russian Roulette with your data integrity. 217 00:10:06.279 --> 00:10:08.799 Could to know We will definitely stick to Docker stock 218 00:10:08.879 --> 00:10:12.039 highly recommended. Now, pulling pre built images from the Docker 219 00:10:12.120 --> 00:10:15.440 hub is fantastic for getting started quickly, but relying on 220 00:10:15.480 --> 00:10:18.480 other people's templates kind of limits you. The true world 221 00:10:18.559 --> 00:10:22.519 changing power of Docker is creating your own custom, repeatable. 222 00:10:22.080 --> 00:10:23.639 Environment, right, taking control. 223 00:10:23.919 --> 00:10:28.159 Yeah, we need to transition from consumers to creators. 224 00:10:27.799 --> 00:10:32.440 And that requires writing the actual code for your infrastructure. Yeah, 225 00:10:32.480 --> 00:10:35.480 which brings us to the most vital file and the ecosystem. Yeah, 226 00:10:35.799 --> 00:10:36.559 the Docker file. 227 00:10:36.600 --> 00:10:39.519 The Docker file, it's essentially the ultimate recipe for an 228 00:10:39.519 --> 00:10:43.200 application environment, right, pretty much. It's a simple declarative text 229 00:10:43.200 --> 00:10:46.480 file that dictates a series of instructions. You always start 230 00:10:46.519 --> 00:10:49.679 with a from command which tells the build engine what 231 00:10:49.840 --> 00:10:54.960 base image to use, like from Ubuntu dot Latest exactly. 232 00:10:55.039 --> 00:10:58.279 You might use maintainer to tag the metadata. Then you 233 00:10:58.399 --> 00:11:01.519 use expos to tell the container firewall to open specific 234 00:11:01.600 --> 00:11:04.559 network ports to the outside world, like port eighty for 235 00:11:04.639 --> 00:11:05.639 standard web traffic. 236 00:11:05.879 --> 00:11:08.799 And eventually you have to inject your actual application code 237 00:11:08.840 --> 00:11:09.720 into this environment. 238 00:11:09.840 --> 00:11:10.799 Right, how do we do that? 239 00:11:10.960 --> 00:11:14.600 The source material highlights two specific instructions for this file transfer, 240 00:11:15.279 --> 00:11:18.720 add and copyy okay. At a glance, they seem to 241 00:11:18.720 --> 00:11:22.720 do the exact same thing, but understanding the underlying causality 242 00:11:22.720 --> 00:11:25.559 between them is critical for security and optimization. 243 00:11:25.720 --> 00:11:26.919 Let's break that down well. 244 00:11:27.000 --> 00:11:30.399 Copyy is highly predictable. It strictly takes a local file 245 00:11:30.519 --> 00:11:33.679 or directory from your host machine and duplicates it inside 246 00:11:33.720 --> 00:11:38.120 the container. ADD however, is a much more complex tool. 247 00:11:38.000 --> 00:11:42.320 Right because add can download files directly from a remote URL, 248 00:11:42.679 --> 00:11:44.639 and if I remember correctly, if you point it at 249 00:11:44.720 --> 00:11:49.000 a local compressed tar archive, it will automatically unpack and 250 00:11:49.080 --> 00:11:52.840 extract that archive directly into the container's file system during 251 00:11:52.840 --> 00:11:53.600 the build. 252 00:11:53.360 --> 00:11:56.360 Which sounds incredibly convenient, right, Yeah, it sounds awesome, but 253 00:11:56.399 --> 00:12:00.240 it introduces severe variables. If you use eighty ds to 254 00:12:00.279 --> 00:12:03.559 pull from a URL, that remote file might change tomorrow 255 00:12:03.600 --> 00:12:07.080 without your knowledge, completely breaking the reproducibility of your build. 256 00:12:07.159 --> 00:12:07.919 Oh true. 257 00:12:07.960 --> 00:12:12.519 Furthermore, auto extracting archives can inadvertently overwrite crucial system files. 258 00:12:12.679 --> 00:12:15.440 If you aren't perfectly aware of what's inside the tarball. 259 00:12:15.120 --> 00:12:17.159 Ah, that could be a disaster exactly. 260 00:12:17.679 --> 00:12:20.879 This is why the community consensus strongly phasers copyy for 261 00:12:20.960 --> 00:12:25.759 moving files. It ensures your build process remains transparent and predictable. 262 00:12:25.840 --> 00:12:30.279 Predictability is key. Now, once the code is safely duplicated inside, 263 00:12:30.320 --> 00:12:32.440 we need to instruct the container on what to do 264 00:12:32.559 --> 00:12:35.159 the moment it boots up. And there is a specific 265 00:12:35.279 --> 00:12:39.399 neurance here regarding the entry point and CMD instructions that 266 00:12:39.559 --> 00:12:41.559 dictates how the final container behaves. 267 00:12:41.879 --> 00:12:45.480 What's fascinating here is how these two commands interact. Entry 268 00:12:45.480 --> 00:12:49.639 point allows you to define a default, unchangeable executable that 269 00:12:49.679 --> 00:12:51.600 will always launch when the container starts. 270 00:12:51.639 --> 00:12:51.879 Okay. 271 00:12:52.279 --> 00:12:55.039 CMB, on the other hand, allows you to pass default 272 00:12:55.159 --> 00:12:59.159 arguments to that executable. But the brilliance of this design 273 00:12:59.639 --> 00:13:02.759 is that the user can override the CMD arguments directly 274 00:13:02.759 --> 00:13:05.200 from the command line when they execute. 275 00:13:04.759 --> 00:13:08.279 Docker run, which fundamentally changes the user experience. 276 00:13:08.320 --> 00:13:08.879 It really does. 277 00:13:09.159 --> 00:13:12.879 Instead of interacting with a clunky virtual machine, the container 278 00:13:12.919 --> 00:13:16.120 behaves exactly like a native command line tool. You just 279 00:13:16.159 --> 00:13:19.440 pass it dynamic variables on the fly, and the internal 280 00:13:19.480 --> 00:13:21.840 executable processes them seamlessly. 281 00:13:22.039 --> 00:13:25.320 It creates a highly dynamic, incredibly flexible tool set. 282 00:13:25.440 --> 00:13:27.840 But you know, as I think about building this recipe out, 283 00:13:27.919 --> 00:13:30.080 I see a massive structural pitfall. 284 00:13:30.200 --> 00:13:30.960 Okay, what's up. 285 00:13:31.039 --> 00:13:33.879 If I'm building an environment, I have to install dependencies. 286 00:13:33.960 --> 00:13:37.399 I'm going to update the package manager, install Python download 287 00:13:37.440 --> 00:13:40.320 system libraries. I'm assuming we use the run command for that. 288 00:13:40.879 --> 00:13:43.559 You do, But the tech states that every single time 289 00:13:43.559 --> 00:13:47.200 you use a run instruction, the Docker engine creates a 290 00:13:47.200 --> 00:13:48.879 brand new layer in the image. 291 00:13:49.200 --> 00:13:50.000 That's correct. 292 00:13:50.440 --> 00:13:53.759 So if I have twenty separate run commands for twenty 293 00:13:53.799 --> 00:13:58.200 different packages, doesn't my final image become bloated and incredibly 294 00:13:58.240 --> 00:13:59.320 inefficient to download? 295 00:13:59.480 --> 00:14:02.440 It would, and if you aren't careful, you end up 296 00:14:02.440 --> 00:14:04.320 with gigabytes of dead space. 297 00:14:04.559 --> 00:14:05.120 Wow. 298 00:14:05.440 --> 00:14:08.279 To understand why, we have to look at the mechanism 299 00:14:08.399 --> 00:14:12.080 of a union file system. Docker images are built out 300 00:14:12.080 --> 00:14:14.559 of a series of read only layers stepped on top 301 00:14:14.639 --> 00:14:18.000 of each other layers. Every time a warru in command executes, 302 00:14:18.159 --> 00:14:21.200 Docker spins up a temporary container runs. Your command takes 303 00:14:21.200 --> 00:14:24.559 a complete snapshot of the filesystem changes, and saves that 304 00:14:24.559 --> 00:14:26.840 snapshot as a permanent immutable layer. 305 00:14:26.960 --> 00:14:27.919 Wait. Immutable. 306 00:14:28.039 --> 00:14:30.759 Yes, So if you download a file on layer three 307 00:14:31.000 --> 00:14:33.559 and then delete that file and layer four, the file 308 00:14:33.639 --> 00:14:36.960 still exists in the layer three snapshots. Seriously, seriously, it 309 00:14:37.000 --> 00:14:38.960 is still taking up space on the hard drive. It's 310 00:14:39.000 --> 00:14:42.039 just hidden from view in the final container. Oh man, 311 00:14:42.480 --> 00:14:44.879 so it's kind of like painting a wall. If you 312 00:14:45.000 --> 00:14:48.399 use twenty separate are you in commands? Docker forces you 313 00:14:48.440 --> 00:14:50.759 to wait for each individual layer of paint to dry 314 00:14:50.960 --> 00:14:54.200 before applying the next, saving a permanent snapshot of the 315 00:14:54.240 --> 00:14:55.480 wall every single time. 316 00:14:55.879 --> 00:14:57.919 That is the perfect way to visualize it, and this 317 00:14:58.000 --> 00:15:01.639 is exactly why optimizing you Docker file is mandatory. 318 00:15:01.759 --> 00:15:02.679 So how do we fix it? 319 00:15:03.120 --> 00:15:05.960 To avoid caching dead space? You must chain your commands 320 00:15:06.000 --> 00:15:08.720 together using the double ampersand the n end symbol. 321 00:15:08.919 --> 00:15:09.679 Ah okay. 322 00:15:09.720 --> 00:15:12.360 Instead of writing run app get update on one line 323 00:15:12.399 --> 00:15:14.679 and r we an app gate installed Python on the next, 324 00:15:14.879 --> 00:15:16.919 you string them into a single run instruction. 325 00:15:17.120 --> 00:15:19.440 So mixing the paint in the bucket first. 326 00:15:19.320 --> 00:15:21.960 Exactly by mixing it first, an apply it in one 327 00:15:22.039 --> 00:15:25.679 single efficient coat, the union file system only takes one snapshot. 328 00:15:25.919 --> 00:15:29.080 The temporary files are downloaded, installed, and deleted, all within 329 00:15:29.120 --> 00:15:32.679 the same layer, resulting in a drastically smaller final image that. 330 00:15:32.720 --> 00:15:36.279 Makes total sense. The source also strongly recommends utilizing a. 331 00:15:36.320 --> 00:15:38.960 Darker nor file right yes, very important. 332 00:15:38.720 --> 00:15:41.840 Much like a dot jitignor file in version control. This 333 00:15:41.919 --> 00:15:46.120 instructs the build engine to completely ignore specific local directories 334 00:15:46.440 --> 00:15:49.600 like your messy testing environments or hidden host system files, 335 00:15:50.000 --> 00:15:53.320 ensuring they don't accidentally get swept up into the container context, 336 00:15:53.480 --> 00:15:54.720 saving even more space. 337 00:15:55.159 --> 00:15:58.320 And we cannot leave the topic of image creation without 338 00:15:58.360 --> 00:16:02.799 mentioning the golden rule of containerization, which is you must 339 00:16:02.840 --> 00:16:07.720 strictly adhere to one application process per container. Do not 340 00:16:07.919 --> 00:16:11.320 bundle your web server, your background worker, and your database 341 00:16:11.720 --> 00:16:13.720 into a single monolithic container. 342 00:16:14.120 --> 00:16:16.879 Isolate them right because keeping them separated means you can 343 00:16:16.960 --> 00:16:19.679 update the database without having to take the web server offline. 344 00:16:19.720 --> 00:16:21.360 Exactly. It's all about modularity. 345 00:16:21.480 --> 00:16:24.879 Now. If you find writing a declarative Docker file tedious, 346 00:16:25.559 --> 00:16:28.879 the text does mention some alternative methods. Yes, if you've 347 00:16:28.919 --> 00:16:31.919 interactively jumped into a container manually tweaked the files, and 348 00:16:31.960 --> 00:16:34.600 want to save your progress, you can type Docker commit 349 00:16:34.679 --> 00:16:37.279 and the demon will snapshot that running state into a 350 00:16:37.279 --> 00:16:38.159 brand new image. 351 00:16:38.320 --> 00:16:38.840 Very handy. 352 00:16:39.120 --> 00:16:42.240 Yeah, you can use a tool like dbootstrap to generate 353 00:16:42.279 --> 00:16:45.840 an image directly from an archive file. Or if you 354 00:16:45.879 --> 00:16:49.279 want total granular control over every single bite, you can 355 00:16:49.320 --> 00:16:51.759 start your Docker file with from scratch. 356 00:16:51.879 --> 00:16:55.159 And starting from scratch gives you an entirely empty file system. 357 00:16:55.559 --> 00:16:57.039 There is no os. 358 00:16:56.759 --> 00:16:58.279 Base just a blank void. 359 00:16:58.480 --> 00:17:02.440 Literally nothing exists untuntil you explicitly inject it, which is 360 00:17:02.639 --> 00:17:06.480 incredibly popular for employing compiled binaries written in languages. 361 00:17:06.160 --> 00:17:07.240 Like Go or Rust. 362 00:17:07.559 --> 00:17:10.480 Okay, let's unpack this. Here's where it gets really interesting. 363 00:17:11.160 --> 00:17:15.839 We have successfully engineered a highly optimized single container running 364 00:17:15.839 --> 00:17:18.839 on our laptop. Nice work, thanks, But a single container 365 00:17:18.880 --> 00:17:23.759 is practically useless in isolation. Real world applications are complex ecosystems. 366 00:17:24.240 --> 00:17:26.839 A modern app demands a front end web container, a 367 00:17:26.920 --> 00:17:30.240 back end API container, a reddis caching layer, and a 368 00:17:30.279 --> 00:17:32.839 persistent database, all communicating securely. 369 00:17:32.920 --> 00:17:34.480 That's a lot of moving parts, it is. 370 00:17:35.079 --> 00:17:37.880 How on earth do we orchestrate that multi container environment 371 00:17:37.880 --> 00:17:40.799 without losing our minds typing endless Docker run commands. 372 00:17:40.839 --> 00:17:42.839 Well, we step out of the core engine and enter 373 00:17:42.920 --> 00:17:47.200 the wider orchestration ecosystem, starting with Docker composed docor composed. 374 00:17:47.319 --> 00:17:47.519 Yes. 375 00:17:48.200 --> 00:17:52.839 Compose was engineered specifically to solve the multi container networking problem. 376 00:17:53.400 --> 00:17:56.960 Instead of manually launching and linking containers via the command line, 377 00:17:57.160 --> 00:18:00.319 you define the entire architecture in a single declarative yamal 378 00:18:00.400 --> 00:18:03.720 file called dockerdash composed dot eml ah. 379 00:18:03.759 --> 00:18:05.960 So back to writing it down as code precisely. 380 00:18:06.440 --> 00:18:09.799 You explicitly map out the services, define which virtual networks 381 00:18:09.839 --> 00:18:12.200 they share, and specify the order in which they must 382 00:18:12.240 --> 00:18:12.680 boot up. 383 00:18:12.920 --> 00:18:15.039 And once that architectural luprint is written, you go to 384 00:18:15.079 --> 00:18:19.319 your terminal and type one single command Docker compose up. 385 00:18:19.200 --> 00:18:21.000 EAA and the magic happens. 386 00:18:21.160 --> 00:18:24.880 Yeah, the tool automatically parses the file, creates the isolated 387 00:18:24.920 --> 00:18:28.279 overlay networks, pulls the necessary images, and boots the entire 388 00:18:28.319 --> 00:18:32.559 stack simultaneously. But my absolute favorite feature of compose is 389 00:18:32.599 --> 00:18:34.000 how it handles load. 390 00:18:34.200 --> 00:18:35.480 Oh, the scaling is brilliant. 391 00:18:35.559 --> 00:18:38.160 Let's say your web app experience as a Sun traffic spike, 392 00:18:38.359 --> 00:18:41.519 and your single front end container is overwhelmed. We compose. 393 00:18:41.680 --> 00:18:43.759 You just type Docker composed scale. 394 00:18:43.440 --> 00:18:46.680 Web three and instantly the demon spins up two additional 395 00:18:46.720 --> 00:18:50.200 identical front end containers to distribute the load that fast. 396 00:18:50.640 --> 00:18:55.119 That fast, it bypasses the entire traditional procurement cycle. You 397 00:18:55.160 --> 00:18:58.920 aren't racking new physical servers or installing operating systems. You 398 00:18:59.000 --> 00:19:01.960 are simply a sting an integer in the command line. 399 00:19:02.079 --> 00:19:04.160 It genuinely feels like a superpower. 400 00:19:04.240 --> 00:19:04.599 It does. 401 00:19:04.920 --> 00:19:08.400