Welcome back. Before we dive in to talking about how we use Docker, we need to cover the high-level concepts. So in this lesson I'll answer the question: What is Docker? So here's my attempt at a simple explanation. Docker is a container platform that allows you to separate your application from the underlying infrastructure by bundling up your code and all of its dependencies into a self-contained entity that will run the same on any supported system.

Picture an actual physical shipping container. You can use a shipping container to transport anything that will fit inside. Since shipping containers come in standard sizes, they're easier to manage because they're consistent. It really doesn't matter what's inside the container because the infrastructure used to transport them is the same.

The ships are able to transport them, cranes are able to move them on and off ships, trucks are able to transport them, and none of that infrastructure is concerned with what's inside the container. When it comes to software development, it's not the initial development that's challenging; it's everything that comes after that.

Deploying code is a challenge. Managing dependencies is a challenge. Handling rollbacks is a challenge. All of these things are made more challenging because the development environments are seldom identical to production, and this is where Docker containers can help. Docker containers are similar to their physical namesake.

They allow you to take whatever software you need to run, bundle it up into a consistent format, and run it on any infrastructure that knows how to handle a container. The end result is kind of like having a single executable for all of your code. It's similar to an app on your phone. All of the code is bundled up into a single unit, and it's going to run the same way on my phone and yours.

With Docker, regardless of the programming language you use or the Linux distribution your code runs on, you can wrap it all up into one unit called a container; and the container knows how to run your app. If your app relies on a specific version of ImageMagick, then you can include it in the container.

Then any time you run that container, you know that you have the correct version. If later you need to update the version of ImageMagick, then you create new container with whatever version you need and any time you run that container, it's going to run correctly because it has everything it needs inside.

Having your code run inside of a container means that it's isolated from other processes and other containers. So each container can have its own process space, its own network stack, resource allocation, et cetera. Docker containers are often compared to virtual machines because VMs are familiar to most IT people.

However, they are pretty different. When you run a virtual machine, the OS that you're using in the VM is running on virtualized hardware. That means that you're using software to emulate hardware and then running a full OS on top. Now virtual machines are great; however, they can be a bit slow to start up, they can consume a lot of resources that you might not need, and they require patching.

Also, they can take up a lot of space on disk, especially considering they contain thousands of files that your app really doesn't need. Here's a diagram from Docker's documentation showing three applications, each running in a VM. So you could imagine that the first one is CentOS, the second is Ubuntu, and the third is Debian.

Each OS is running on the hypervisor and consuming a lot of system resources. Now here's a look at how Docker is different. Notice the host OS and then the Docker engine here in place of the guest OS. So then you have your binaries and libraries that your application needs followed by your application code.

So what Docker is doing is it's cutting out the guest OS, allowing you to bundle up the system libraries, any binaries that your app needs, as well as your code, all into one unit that can be executed via the Docker engine. Where VMs run the entire OS, Docker shares the kernel with the host OS. This means that containers can start up about as quickly as any other process since they really don't contain all of the files required to run the entire OS, and they don't consume all of the resources that a guest OS does.

So it allows you to run more of them on the same hardware. In Linux, everything is just a file, which means the difference between Ubuntu and CentOS is really just a set of files. By files, I mean things like binaries for package management, configuration files, different services, et cetera. With Docker, you use the kernel of the host OS.

However, because the difference between distributions is really just different files, you can create Docker containers based on the different distributions. So if your application requires some libraries that run on Ubuntu, then you base your container on Ubuntu. This means you can bundle up your code, as well as just the system libraries that you need, into one container.

Once all of your code and dependencies are in a container, they're going to run the same way anywhere because everything required to have the code run is inside the container. So if you use Docker containers for all of your applications, then that's going to allow you to standardize on how you deploy all of your applications.

All right, admittedly, this is an intentionally overly simplistic explanation of Docker. However, it should serve as a solid enough intro that we can build on that in the following lessons. So if you're ready to dive a little bit deeper, let's cover the architecture of Docker in the next lesson. So if you're ready, I'll see you in the next lesson.