Never install locally

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.