Not much to say that docker is a more excellent virtual machine-like system with independent storage space. It has many excellent ideas, such as absorbing the idea of git storage warehouse, and using image to refer to the warehouse in git.
Hierarchical storage of docker
When Docker was designed, it made full use of the technology of Union FS and designed it as a tiered storage architecture. So strictly speaking, an image is not a packaged file like an ISO. An image is just a virtual concept. Its actual manifestation is not composed of a file, but a set of file systems, or a combination of multi-layer file systems. composition.
When mirroring is built, it will be built layer by layer, and the former layer is the foundation of the latter layer. After each layer is constructed, there will be no changes, and any changes on the latter layer will only occur on your own layer. For example, the operation of deleting the file of the previous layer does not actually delete the file of the previous layer, but only marks the file as deleted in the current layer. When the final container runs, although this file will not be seen, in fact the file will always follow the image. Therefore, when building the image, you need to be extra careful. Each layer should only contain what needs to be added to the layer, and any extra things should be cleaned up before the end of the layer construction.
The feature of hierarchical storage also makes it easier to reuse and customize mirroring. You can even use the previously built image as the base layer, and then further add new layers to customize what you need and build a new image.
The relationship between the image (Image) and the container (Container) is like a class and instance in object-oriented programming. The image is a static definition, and the container is the entity of the image at runtime. Containers can be created, started, stopped, deleted, suspended, etc.
The essence of a container is a process, but unlike a process that executes directly on the host, a container process runs in its own independent namespace. Therefore, the container can have its own root file system, its own network configuration, its own process space, and even its own user ID space. The process in the container runs in an isolated environment, and when used, it is as if operating under a system independent of the host. This feature makes container-encapsulated applications safer than running directly on the host. Because of this isolation feature, many people often confuse containers and virtual machines when they first learn Docker.
As mentioned earlier, mirroring uses tiered storage, and the same is true for containers. When each container is running, the image is the base layer, and a storage layer of the current container is created on it. We can call this storage layer prepared for reading and writing during container runtime as the container storage layer.
The life cycle of the container storage layer is the same as that of the container. When the container dies, the container storage layer also dies. Therefore, any information stored in the storage layer of the container will be lost when the container is deleted.
According to the requirements of Docker's best practices, the container should not write any data to its storage layer, and the container storage layer should remain stateless. All file write operations should use data volumes (Volume) or bind the host directory. Reading and writing at these locations will skip the container storage layer and directly read and write to the host (or network storage). Higher stability.
The life cycle of the data volume is independent of the container, and the container dies, and the data volume will not die. Therefore, after the data volume is used, the data will not be lost after the container is deleted or re-run.
The function of the docker warehouse is similar to that of the git warehouse, which will not be explained here. Here we mainly discuss the special naming rules of the docker warehouse.
Take the Ubuntu image as an example, ubuntu is the name of the warehouse, which contains different version labels, such as 14.04, 16.04. We can use ubuntu:14.04 or ubuntu:16.04 to specify which version of the image is required. If the tag is omitted, such as ubuntu, it will be treated as ubuntu:latest.
The warehouse name often appears in the form of a two-part path, such as jwilder/nginx-proxy. The former often means the user name in the Docker Registry multi-user environment, and the latter is often the corresponding software name. But this is not absolute, it depends on the specific Docker Registry software or service used.