Byte Two: You write proficient docker in your resume, can you talk about the difference between containers and mirroring?

This article introduces the difference between containers and mirrors and the technical details behind each command of Docker Docker in depth.

This article hopes to help readers deeply understand Docker , as well as the difference between container and image, and delve into the difference between container and running container.

When I had Docker technology, I found it very difficult to Docker So, I spent a few weeks to learn Docker , more specifically, about the Docker unified file system (the union file system), and then look back at Docker Command, everything becomes logical and simple.

Image Definition

Image is a unified perspective of a bunch of read-only layers. Perhaps this definition is a bit difficult to understand. The following picture can help readers understand the definition of mirroring.

From the left we see multiple read-only layers, which overlap each other. Except for the bottom layer, other layers will have a pointer to the next layer. These layers are the Docker , and can be accessed on the file system of the host (Translator's Note: Docker The unified file system (union file system) technology can integrate different layers into a file system, providing a unified perspective for these layers, so that the existence of multiple layers is hidden. From the user's point of view, there is only one file system. We can see the form of this perspective on the right side of the picture.

You can find files about these layers on your host file system. It should be noted that these layers are not visible inside a running container. On my host, I found that they exist in the /var/lib/ docker /aufs directory.

sudo tree -L 1 /var/lib/docker/
/var/lib/docker/
├── aufs
├── containers
├── graph
├── init
├── linkgraph.db
├── repositories-aufs
├── tmp
├── trust
└── volumes
7 directories, 2 files

Container Definition

The definition of a container is mirror image (image) . It is also a unified perspective of a stack of layers. The only difference is that the top layer of the container is readable and writable.

Careful readers may find that container does not mention whether the container is running, yes, this is intentional. It was this discovery that helped me understand a lot of confusion.

Key points: container = image + readable layer. And the definition of the container does not mention whether to run the container.

Next, we will discuss running containers.

Running Container Definition

A running container is defined as a readable and writable unified file system plus an isolated process space and the processes contained in it. The picture below shows a running container.

It is the file system isolation technology that makes Docker a promising technology. A process in a container may modify, delete, or create files, and these changes will affect the read-write layer. The image below shows this behavior.

We can verify what we said above by running the following command:

docker run ubuntu touch happiness.txt

Even if the ubuntu container is no longer running, we can still find the new file on the host's file system.

find / -name happiness.txt/var/lib/docker/aufs/diff/860a7b...889/happiness.txt

Image Layer Definition

In order to integrate the scattered data, we proposed the concept of image layer. The following picture describes a mirrored layer. Through the picture, we can find that a layer not only contains changes to the file system, it can also contain other important information.

Metadata is additional information about this layer. It not only allows Docker obtain information at runtime and build time, but also includes the level information of the parent layer. It should be noted that both the read-only layer and the read-write layer contain metadata.

In addition, each layer includes a pointer to the parent layer. If a layer does not have this pointer, it means it is at the bottom.

Metadata Location:

I found that on my own host, the metadata of the image layer is stored in a file named "json", for example:

/var/lib/docker/graph/e809f156dc985.../jsone809f156dc985...  #就是这层的id 

The metadata of a container seems to be divided into many files, but it can be more or less found in the /var/lib/ docker /containers/<id> directory. <id> is the id of a readable layer. The files in this directory are mostly run-time data, such as network, log, etc.

Global Understanding (Tying It All Together)

Now, let us combine the implementation details mentioned above to understand the Docker command.

docker create <image-id>

docker create command adds a read-write layer to the specified image (image) to form a new container. Note that this container is not running.

docker start <container-id>

Docker start command creates a process isolation space for the container file system. Note that each container can only have one process isolation space.

docker run <image-id>

Reading this command, readers usually have a question: what is the difference between docker start and docker run commands.

As you can see from the picture, the docker run command first creates a container using the image, and then runs the container. This command is very convenient and hides the details of the two commands, but on the other hand, it is easy to misunderstand users.

docker ps

The docker ps command will list all running containers. This hides the existence of non-running containers. If we want to find these containers, we need to use the following command.

docker ps –a

The docker ps -a command will list all containers, whether they are running or stopped.

docker images

The docker images command will list all top-level images. In fact, here we have no way to distinguish between a mirror and a read-only layer, so we propose a top-level mirror. Only the image used when creating the container or the image directly pulled down can be called a top-level image, and there are multiple image layers hidden under each top-level image.

docker images –a

The docker images -a command lists all the images, it can also be said that it lists all the readable layers. If you want to view all the layers under a certain image-id, you can use docker history to view.

docker stop <container-id>

The docker stop command sends a SIGTERM signal to the running container, and then stops all processes.

docker kill <container-id>

The docker kill command sends an unfriendly SIGKILL signal to all processes running in the container.

docker pause <container-id>

The docker stop and docker kill commands send UNIX signals to the running process. The docker pause command is different. It uses the characteristics of cgroups to pause the running process space. The specific internal principle can be found here: https://www.kernel.org/doc/Doc ... m.txt, but the disadvantage of this method is that sending a SIGTSTP signal is not enough for the process It is so simple and easy to understand that it is impossible to pause all processes.

docker rm <container-id>

![Picture]

The docker rm command will remove the read-write layer that makes up the container. Note that this command can only be executed on non-running containers.

docker rmi <image-id>

The docker rmi command removes a read-only layer that constitutes the image. You can only use docker rmi to remove the top level layer (or mirroring), and you can also use the -f parameter to force the deletion of the middle read-only layer.

docker commit <container-id>

The docker commit command converts the readable and writable layer of the container into a read-only layer, thus turning a container into an immutable image.

docker build

The docker build command is very interesting, it will execute multiple commands repeatedly.

As we can see from the above figure, the build command obtains the image according to the FROM instruction in the Dockerfile file, and then repeatedly 1) run (create and start), 2) modify, and 3) commit. Each step in the loop will generate a new layer, so many new layers will be created.

docker exec <running-container-id>

The docker exec command executes a new process in the running container.

docker inspect <container-id> or <image-id>

The docker inspect command will extract the top-level metadata of the container or image.

docker save <image-id>

The docker save command will create a compressed file of the image, which can be used on Docker on another host. Unlike the export command, this command saves their metadata for each layer. This command can only be effective for mirroring.

docker export <container-id>

The docker export command creates a tar file, removes metadata and unnecessary layers, integrates multiple layers into one layer, and only saves the content seen from the current unified perspective. Import to Docker, only one image can be seen through the docker images -tree command; the image after save is different, it can see the historical image of this image).

docker history <image-id>

The docker history command recursively outputs the historical image of the specified image.

For more information about Docker commands, please refer to the article: These 20 Docker Commands, how many do you know?

Author: bethal
Source: https://www.cnblogs.com/bethal/p/5945038.html