Detailed explanation of the Docker container lifecycle architecture and the differences between it and VM

Container lifecycle

The life cycle of a container runtime

A container is a set of processes with isolation characteristics. When using docker run, an image is selected to provide an independent file system and specify the corresponding running program. The running program specified here is called the initial process. When the initial process starts, the container will also start. When the initial process exits, the container will also exit.

Therefore, it can be considered that the life cycle of the container is consistent with the life cycle of the initial process. Of course, because there is more than one initial process in the container, the initial process itself can also generate other subprocesses or operation and maintenance operations generated by docker exec, which also fall within the scope of initial process management. When the initial process exits, all child processes will also exit, which is also to prevent resource leakage.

However, this approach also has some problems. First, the programs in the application are often stateful and may generate some important data. When a container exits and is deleted, the data will be lost, which is unacceptable to the application party. Therefore, the important data generated by the container needs to be persisted. The container can persist data directly to a specified directory, which is called a data volume.

Data volumes have some characteristics, one of which is that the life cycle of a data volume is independent of the life cycle of a container. In other words, operations such as creating, running, stopping, and deleting a container have nothing to do with a data volume because it is a special directory that is used to help containers persist. In simple terms, we will mount the data volume into the container, so that the container can write data to the corresponding directory, and exiting the container will not result in data loss.

Generally, there are two main ways to manage data volumes:

The first method is to directly mount the host directory into the container through bind. This method is relatively simple, but it will bring operation and maintenance costs because it depends on the host directory and requires unified management of all hosts.

The second is to hand over directory management to the runtime engine.

Container project architecture

Moby container engine architecture

Moby is the most popular container management engine. Moby daemon provides management of containers, images, networks, and volumes. The most important component that moby daemon depends on is containerd. Containerd is a container runtime management engine that is independent of moby daemon and can provide container and image management.

The underlying layer of containerd is the containerd shim module, which is similar to a daemon process. There are several reasons for this design:

First, containerd needs to manage the container lifecycle, and containers may be created by different container runtimes, so a flexible plug-in management is needed. Shim is developed for different container runtimes, so it can be separated from containerd and managed through plug-ins.

Secondly, because shim is implemented as a plug-in, it can be dynamically taken over by containerd. Without this capability, when the moby daemon or containerd daemon exits unexpectedly, the container will be unmanaged and will disappear or exit, affecting the operation of the application.

Finally, because moby or containerd may be upgraded at any time, if the shim mechanism is not provided, it will be impossible to upgrade in place or without affecting the business. Therefore, containerd shim is very important, as it implements the ability of dynamic takeover.

The above is just a general introduction to moby.

Containers vs VMs

Differences between containers and VMs

VM uses Hypervisor virtualization technology to simulate hardware resources such as CPU and memory, so that a Guest OS can be established on the host machine, which is often referred to as installing a virtual machine.

Each Guest OS has an independent kernel, such as Ubuntu, CentOS, and even Windows. Under such a Guest OS, each application is independent of each other, and VM can provide a better isolation effect. However, this isolation effect requires a certain price, because part of the computing resources must be handed over to virtualization, which makes it difficult to fully utilize the existing computing resources. In addition, each Guest OS requires a large amount of disk space. For example, the installation of the Windows operating system requires 10~30G of disk space, and Ubuntu also requires 5~6G. At the same time, this method starts very slowly. It is precisely because of the shortcomings of virtual machine technology that container technology was born.

Containers are for processes, so there is no need for a Guest OS. Only an independent file system is needed to provide the required file set. All file isolation is at the process level, so the startup time is faster than VM and the required disk space is also smaller than VM. Of course, process-level isolation is not as good as imagined, and the isolation effect is much worse than that of VM.

Overall:

Compared with VMs, containers have their own advantages and disadvantages, so container technology is also developing towards strong isolation.

The above article about the Docker container lifecycle architecture and its differences from VM is all I have to share with you. I hope it can give you a reference. I also hope that you will support 123WORDPRESS.COM.