and I don't just mean your code and its libraries, I mean the OS too, all pre-configured to run as soon as you deploy it. That's a container. They're lightning fast, portable, yet isolated environments that you can create in mere moments, and after this video you're going to wonder how you ever developed and deployed applications without them. But that's just a VM! No, firstly, please sit down. Secondly, no, not quite. Okay, it's true that both give you an isolated environment where you can run an OS, but containers are quite a bit quicker to spin up, and typically less resource intensive. If there was a scale with VMs on one side and normal native applications on the other, containers would sit somewhere in the middle. Virtual machines are pretty much just tricked by the host's hypervisor layer into thinking they're actually running on real hardware. Containers, on the other hand, are more friendly with the host system and just emulate a minimal file system, while piggybacking resources by sharing the host's kernel. The kernel is the... no, not that kernel. Close enough. The kernel is the core of any operating system. It's the bridge between what the software asks for and what the hardware actually does. It's responsible for all sorts of critical low-level tasks like CPU and memory management, device I.O., file systems, and process management. So how does this all help us as developers? Well, now that we have an OS at our fingertips, we can work in several different environments at once without having to really compromise anything on our local machine. For example, we can maintain an old app using the OS and package dependencies it was originally built on top of, while also being able to use bleeding edge tech for our next multi-million dollar project without having to worry about any conflicts in doing so. We're also now able to put an end to the it works on my machine problem, which is a pretty common phrase to hear in the tech industry, unfortunately. Because a container is essentially a full OS at its core, you can be sure that wherever it runs you're going to get the exact same environment, whether it's on your colleague's machine, your server machine, or somewhere in the cloud. Now we've got the basics out of the way. Let's see how we can make a container of our own. The first thing we're going to need is a container platform. This will give us all the tools we need to create and run our container, and for this video I'll be using Docker, just because it's the most well supported. All containers run from a base file system and some metadata, presented to us as a container image. And the way container images work is kind of fascinating, because they are formed with overlapping layers. Here's a banana to kind of badly demonstrate this idea. Okay, so in the context of a file system, I mean that instead of changing data at its source, file changes are tracked by their differences to the previous layer, and then composed together to achieve the final system state. It's somewhat similar to how source control tracks changes in your code. This concept is really powerful for containers, because it lets us extend our custom image from any previous image or image layer. There's loads of pre-made and officially supported base images out there, that you can match to your project's core requirements, and then add your own packages, code and configuration to. To do this in Docker, we add the commands we want to execute to a file called a Dockerfile. Docker will execute each command in sequence, and then add each generated change to the final image as a new file system layer, or a metadata layer. We can run as many containers as we like from a single image. We can do this because when a container is first created, the image's file system is extended with a new file system layer, completely dedicated to that container. This means that we can make any runtime changes we like, and it won't affect other containers using that same image. What's more, this new layer will persist until we delete the container, so we can stop and start them as we like, without losing any data. We can even enter our running containers, like we do with a VM. With Linux containers, for example, we can start a shell prompt when executing it, giving us access to the environment to explore and kind of just play around with as we please. Communication between containers is usually pretty simple as well, as most runtimes virtualize a network layer for you. When our app is ready to be published into the world, we're going to want to tag it with something unique, like a version, so that we can reference it again later. We can then publish it to something called a container registry, which is just like an online storage warehouse for our images. By default, Docker assumes that you're using the official Docker registry. However, this can be easily overridden if you wish to use another. When it comes to deployment, many modern cloud platforms have built-in support for deploying containers as standalone units. Alternatively, you can install a compatible container runtime on whatever machine you want to use, and pull your image from the registry you pushed to earlier. It does require a few more steps doing it this way, but you generally get better value for money and quite a bit more control. If you want to go even deeper, container orchestration platforms such as Kubernetes essentially allow you to create your own container-based cloud. You describe the desired state of your deployment declaratively, and let Kubernetes handle the details of how to get there. And that's it. Oh, I'd really love to make these videos full-time for you all, and with enough support, that might just be possible. Thank you, and I'll see you next time.
