Why Docker
Why Containers
Containers make deployment easy. Deploying is as simple as running a new container, routing users to the new one, and trashing the old one. It can even be automated by orchestration tools. Since it’s so easy, we can afford to have many containers serving a single application for increased stability during updates.
If you don’t use containers, Ops need to handle your hosting environment: runtimes, libraries, and OS needed by your application. On the other hand, when using containers, they need one single methodology that can handle the containers you provide no matter what’s inside them. You may as well use .NET Core, Java, Node.JS, PHP, Python, or another development tool: it doesn’t matter to them as long as your code is containerized. This is a considerable advantage for containers when it comes to DevOps.
Solves Dependency Conflicts
Containers solve this problem since each app will run inside its own container with its own dependencies. Your typical server would look like:
Each container encapsulates its own dependencies. Which means you can migrate the PHP runtime from version 5.6 to 7.2 in a container without it affecting others. Any other container that would use, for instance, Node.JS would not interfere with any of the WordPress containers.
Allows Easy Scaling Up
Again, containers have a solution for this. As we’ll see in the Basic Concepts chapter, containers are based on images. You can run as many containers as you wish from a single image — all the containers will support the exact same dependencies.
Better yet: when using an orchestrator, you merely need to state how many containers you want and the image name and the orchestrator creates that many containers on all of your Docker servers. We’ll see this in the orchestrators part of this course. This is how it looks:
Allows Seamless Upgrades
By using containers, it’s a simple matter of telling the orchestrator that you want to run a new image version, and it gradually replaces every container with another one running the new version. Whatever technology stack is running inside the containers, telling the orchestrator that you want to run a new image version is a simple command (in fact, by changing just one line, as we’ll see).
The illustration below shows the process as it goes on: the orchestrator replaces one container, and then moves on to the other ones. While the new container is not ready, traffic is being routed to the old version containers so that there is no interruption of service.
Basic Concepts
Containers
A container is what we eventually want to run and host in Docker. You can think of it as an isolated machine, or a virtual machine if you prefer.
From a conceptual point of view, a container runs inside the Docker host isolated from the other containers and even the host OS. It cannot see the other containers, physical storage, or get incoming connections unless you explicitly state that it can. It contains everything it needs to run: OS, packages, runtimes, files, environment variables, standard input, and output.
Your typical Docker server would look like this — a host for many containers:
The fact that there are two app2 containers in the schema above is normal; this is typically the case when a server hosts a release and a test version. Which means you could host both versions on the same server. In fact, each container has its own ID, but let’s keep things simple for now.
Images
Any container that runs is created from an image. An image describes everything that is needed to create a container; it is a template for containers. You may create as many containers as needed from a single image.
The whole picture looks like:
Registries
Images are stored in a registry. In the example above, the app2 image is used to create two containers. Each container lives its own life, and they both share a common root: their image from the registry.
In the coming chapters, you’re going to learn how to run containers from existing images, then you’ll learn how to create your own images and also upload them to registries.