"Editor's note" This article describes the differences between containers, mirrors, and the technical details behind each of the Docker commands in an illustrated way to help readers understand Docker well.
This article hopes to help readers understand the differences between the Docker commands, the container (container) and the image (image), and delve into the differences between the containers and the containers that are running.
When I was smattering with Docker technology, I found it very difficult to understand Docker's commands. So it took me weeks to learn how Docker works, or rather, about the Docker unified FileSystem (the Union file System), and then looking back at Docker's commands, it all became logical and simple.
Aside: Personally, the best way to master a technology and use it wisely is to understand how the technology works. Usually, the birth of a new technology is often accompanied by media hype and speculation, which makes it difficult for users to see the nature of technology. More precisely, the new technology will always invent a number of novel terms or metaphorical words to help promote propaganda, which is very helpful at the beginning, but this gives the principle of technology coated with sandpaper, not conducive to the user in the late mastery of the true meaning of technology.
Git is a good example. I wasn't able to use git very well before, so it took me a while to learn how git works, until then I really understood git's usage. I firmly believe that only people who really understand the internal principles of Git can master this tool.
The image definition image is a unified view of a stack of read-only layers (read-only layer), which may be difficult to understand, and this diagram will help the reader understand the definition of the image.
From the left we see multiple read-only layers, which overlap. In addition to the bottom layer, the other layers will have a pointer pointing to the next layer. These layers are implementation details inside Docker and can be accessed on the file system of the host (translator: the machine running Docker). The Unified FileSystem (Union file System) technology enables the integration of different layers into a single file system, providing a unified perspective for these layers, thus hiding the existence of multiple layers, and in the user's view, there is only one filesystem. We can see the form of this perspective on the right side of the picture.
You can find files on these layers on your host file system. It is important to note that these layers are not visible inside a running container. On my console, 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└── Volumes7 directories, 2 files
The definition and image (image) of the Container definition container (Container) is almost identical, and is a unified view of a stack of layers, the only difference being that the topmost layer of the container is readable and writable.
The careful reader may find that the container definition does not mention whether the container is running, yes, it is intentional. It was this discovery that helped me understand a lot of confusion.
Important: Container = mirror + readable layer. And the container definition does not mention whether or not to run the container.
Next, we'll discuss the run-state container.
Running Container definition a run-state container (Running Container) is defined as a read-write unified file system coupled with isolated process space and processes contained therein. The following image 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, and create files that will be used for the read-write layers (read-write layer). The following diagram shows this behavior.
We can verify what we said above by running the following command:
Docker run Ubuntu Touch happiness.txt
Even if this Ubuntu container is no longer running, we can still find this new file on the host filesystem.
Find/-name Happiness.txt
/var/lib/docker/aufs/diff/860a7b ... 889/happiness.txt
Image layer definition in order to integrate the scattered data, we present the concept of the image layers. The following diagram depicts a mirrored layer, through which we can find a layer that not only contains changes to the file system, but also contains other important information.
Metadata (metadata) is the additional information about this layer, which not only allows Docker to get information about when it runs and builds, but also includes hierarchical information from the parent layer. It is important to note that both read-only and read-only layers 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 in my own host, the metadata for the image layer is stored in a file called "JSON", such as:
/var/lib/docker/graph/e809f156dc985.../json
e809f156dc985 ... That's the ID of this layer.
The metadata for a container seems to be broken down into many files, but more or less can be 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 networks, logs, and so on.
Global understanding (tying It all Together) Now let's understand Docker's commands in conjunction with the implementation details mentioned above.
Docker Create <image-id>
The docker create command adds a readable layer to the specified image (image), which forms a new container. Note that this container is not running.
Docker start <container-id>
The Docker Start command creates a process isolation space for the container file system. Note that each container can have only one process isolation space.
Docker Run <image-id>
When you see this command, the reader usually has a question: what is the difference between a docker start and a docker Run command?
As you can see from the picture, the Docker Run command first creates a container with the image and then runs the container. This command is very handy and hides the details of two commands, but on the other hand, it's easy for users to misunderstand.
Digression: Go ahead and we have a conversation about git, and I think the Docker Run command is similar to the git pull command. The git pull command is a combination of git fetch and git merge two commands, and, similarly, Docker run is a combination of the Docker create and Docker start two commands.
Docker PS
The Docker PS command lists all the containers that are running. This hides the presence of non-running containers, and if you want to find these containers, we need to use the following command.
Docker Ps–a
The Docker ps–a command lists all the containers, whether they are running or stopping.
Docker images
The docker images command lists all the top-level (top-level) images. In fact, here we have no way to distinguish between a mirror and a read-only layer, so we present a top-level image. Only the mirrors used to create the container, or the mirrors that pull down directly, can be called top-level (top-level) mirroring, and multiple mirrored layers are hidden underneath each of the top-level mirrors.
Docker Images–a
The Docker images–a command lists all of the mirrors, or lists all the readable layers. If you want to see all the layers under a image-id, you can use Docker history to view them.
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 command sends a UNIX signal to a running process, unlike the Docker Pause command, which takes advantage of the cgroups feature to pause the running process space. Specific internal principles you can find here: Https://www.kernel.org/doc/Doc ... m.txt, but the disadvantage of this approach is that sending a SIGTSTP signal is not simple enough for the process to be able to pause all processes.
Docker RM <container-id>
The Docker RM command removes the read-write layer that makes up the container. Note that this command can only be performed on non-running containers.
Docker RMI <image-id>
The Docker RMI command removes a read-only layer that makes up the image. You can only use the Docker RMI to remove the topmost (top level layer) (or mirror), or use the-f parameter to force the deletion of the intermediate read-only layer.
Docker Commit <container-id>
The Docker commit command transforms a container's read-write layer into a read-only layer, which transforms a container into an immutable image.
Docker Build
The Docker build command is interesting, and it executes multiple commands repeatedly.
As we can see, the build command gets to the mirror based on the from instruction in the Dockerfile file and then repeats 1) run (Create and start), 2) modify, 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 extracts the metadata from the container or the topmost layer of the image.
Docker Save <image-id>
The Docker Save command creates a mirrored compressed file that can be used on another host's Docker. Unlike the Export command, this command stores their metadata for each layer. This command is only valid for mirroring.
Docker Export <container-id>
The Docker Export command creates a tar file and removes the metadata and unnecessary layers, consolidating multiple layers into a single layer, preserving only what is seen at the current unified perspective (Translator Note: EXPOXT containers are then import into Docker, via Docker The Images–tree command sees only one image, and the image after save is different, and it can see the historical image of the image.
Docker History <image-id>
The Docker History command outputs the historical image of the specified image recursively.
Conclusion I hope you will enjoy this article. There are many other commands (Pull,search,restart,attach, etc.) I did not mention, but I believe most of the Docker commands can be well understood by reading this article. I've only studied Docker for two weeks, so if I have a bad place to say it, you are welcome to point it out.
Docker Knowledge-1
