Detailed explanation of Docker working mode and principle

As shown in the following figure:

When we use virtual machines and Docker, a question arises: Why is Docker faster than VM?

The picture above objectively illustrates this problem.

1. Docker has fewer abstraction layers than virtual machines.

2. Docker uses the kernel of the host machine, while VM requires the Guest OS.

Therefore, when creating a new container, Docker does not need to reload an operating system like a virtual machine. The virtual machine loads the Guest OS (taking time in minutes), while Docker uses the host machine's operating system, omitting this complex process (taking time in seconds).

After clarifying these, let's take a look at how we use it on the client side.

First, we need to understand a few terms:

Host (Docker Engine)

A physical or virtual machine used to execute the Docker daemon and containers.

Image

What is a Docker image? Simply put, a Docker image is a Linux file system (Root FileSystem), which contains programs that can run on the Linux kernel and the corresponding data.
A container is started through an image. An image is an executable package that includes everything needed to run an application: code, runtime, libraries, environment variables, and configuration files.
Docker packages the App files into a mirror and uses storage technology similar to multiple snapshots to achieve:

• Multiple apps can share the same underlying image (initial operating system image);
• Isolation of IO operations and image files during App runtime;
• By mounting directories or volumes containing different configuration/data files, a single App image can be used to run numerous containers for different businesses.

Container

The relationship between an image and a container is like that between a class and an instance in object-oriented programming. An image is a static definition, and a container is an entity at the runtime of the image. Containers can be created, started, stopped, deleted, paused, etc.

Image layering

Docker supports creating new images by extending existing images. In fact, 99% of the images in Docker Hub are built by installing and configuring the required software in the base image.

As can be seen from the above figure, the new image is generated by stacking the base image layer by layer. Every time you install a piece of software, you add a layer to the existing image.
One of the biggest benefits of image layering is shared resources. For example, if multiple images are built from the same base image, the Docker Host only needs to save one base image on disk; at the same time, only one base image needs to be loaded into memory to serve all containers. And each layer of the image can be shared.
If multiple containers share a base image, when a container modifies the content of the base image, such as files under /etc, the /etc of other containers will not be modified, and the modification will be limited to a single container. This is the container Copy-on-Write feature.

Writable container layer

When the container starts, a new writable layer is loaded on top of the image. This layer is usually called the "container layer", and everything below the "container layer" is called the "image layer".

All changes to the container - whether adding, deleting, or modifying files - only happen at the container level. Only the container layer is writable, and all image layers below the container layer are read-only.

There may be a large number of image layers, and all image layers will be combined together to form a unified file system. If there is a file with the same path in different layers, such as /a, the /a in the upper layer will overwrite the /a in the lower layer, which means that the user can only access the file /a in the upper layer. In the container layer, what the user sees is a superimposed file system.

Data is copied only when it needs to be modified. This feature is called Copy-on-Write. It can be seen that the container layer saves the changed part of the image and does not make any modifications to the image itself.

To sum up: the container layer records the changes to the image, all image layers are read-only and will not be modified by the container, so the image can be shared by multiple containers.

Volume

In fact, our container is like a simplified version of an operating system, except that the system only installs the environment required for our program to run. As mentioned earlier, our container can be deleted. If it is deleted, what should we do with the data that needs to be persisted generated by the program in the container? When the container is running, we can enter the container to view it. Once the container is deleted, there will be nothing left.

So the data volume is used to solve this problem. It is used to persist data on our host machine and realize data sharing between containers. Simply put, it maps the host machine's directory to the directory in the container. The application reads and writes data in the directory in the container and the data will be synchronized to the host machine. In this way, the data generated by the container can be persisted. For example, our database container can store data in the real disk on our host machine.

Registry

Docker uses Registry to store user-built images. There are two types of registries: public and private. Docker Inc. operates a public registry called Docker Hub. Users can register an account on Docker Hub to share and save their own images.

Docker provides a public image repository hub.docker.com (Docker calls it Repository) that provides a huge collection of images for use.

A Docker Registry can contain multiple repositories; each repository can contain multiple tags; each tag corresponds to an image.

Typically, a repository contains images of different versions of the same software, and tags correspond to different versions of the software. We can use the format of <warehouse name>:<label> to specify which version of the software is the mirror. If no tag is given, the default tag is latest.

Summarize

The Docker official website has a sentence like this: Build and Ship any Application Anywhere. Combined with what we just understood, the summary is: build once, run everywhere.
In addition, Docker provides a public image repository hub.docker.com (Docker calls it Repository), GitHub connect, which automatically builds images, greatly simplifying the application distribution, deployment, and upgrade processes. In addition, Docker can easily create various customized image files, which are important factors for Docker to become the most popular container technology.

Through the combination of the above technologies, the final result is: for most applications, developers can create images through docker build, upload images through docker push, users can download images through docker pull, and run container applications with docker run. Users no longer need to worry about how to build the environment, how to install, or how to resolve library conflicts between different distributions - and it usually does not consume more hardware resources or significantly reduce performance.

The above is the detailed content of the detailed explanation of Docker's working mode and principle. For more information about Docker's working mode and principle, please pay attention to other related articles on 123WORDPRESS.COM!