basic concept
Docker includes three basic concepts
Image (Image)
Container (Container)
Repository (Repository)
After understanding these three concepts, you understand the entire life cycle of Docker.
Docker image
We all know that the operating system is divided into kernel and user space. For Linux, after the kernel is started, the root file system is mounted to provide user space support. The Docker image (Image) is equivalent to a root file system. For example, the official image ubuntu:16.04 contains a complete set of root file systems of the Ubuntu 16.04 minimal system.
Docker image is a special file system. In addition to providing programs, libraries, resources, configuration and other files required for container runtime, it also contains some configuration parameters prepared for runtime (such as anonymous volumes, environment variables, users, etc. ). The image does not contain any dynamic data and its contents will not be changed after construction.
Tiered storage
Because the image contains the complete root file system of the operating system, its volume is often huge. Therefore, when Docker is designed, it makes full use of the technology of Union FS and designs it as a hierarchical storage architecture. So strictly speaking, an image is not a packaged file like an ISO, an image is just a virtual concept, and 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 the image is built, it will be built layer by layer, and the previous layer is the foundation of the next layer. After each layer is built, it will not change, and any changes on the next layer will only happen to its own layer. For example, the operation of deleting a file in the previous layer does not actually delete the file in 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 images, extra care is needed, and each layer should try to contain only the things that need to be added to that layer. Any extra things should be cleaned up before the end of the layer's construction.
The feature of tiered storage also makes it easier to reuse and customize images. You can even use a previously built image as a base layer, and then further add new layers to customize what you need to build a new image.
About image construction, it will be further explained in subsequent relevant chapters.
Docker container
The relationship between an image and a container is like a class and instance in object-oriented programming. An image is a static definition, and a container is an entity when the image is run. Containers can be created, started, stopped, deleted, suspended, etc.
The essence of a container is a process, but unlike the process executed directly on the host, the container process runs in its own independent namespace. So a container can have its own root filesystem, its own network configuration, its own process space, and even its own user ID space. The processes in the container run in an isolated environment and are used as if they were operating under a system independent of the host. This feature makes container-packaged applications more secure than running directly on the host. Because of this isolation, many people often confuse containers and virtual machines when they are new to Docker.
As mentioned earlier, images use tiered storage, and so do containers. Each container runtime uses the image as the base layer to create a storage layer of the current container 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 container storage layer will be lost when the container is deleted.
According to the requirements of Docker best practices, containers should not write any data to their storage layer, and the container storage layer should remain stateless. All file writing operations should use a data volume (Volume) or bind the host directory. Read and write in these locations will skip the container storage layer and directly read and write to the host (or network storage). Its performance and Higher stability.
The life cycle of the data volume is independent of the container. When the container dies, the data volume does not die. Therefore, after using the data volume, the data will not be lost after the container is deleted or re-run.
Docker Registry
After the image is constructed, it can be easily run on the current host. However, if the image needs to be used on other servers, we need a centralized service for storing and distributing images. Docker Registry is such a service.
A Docker Registry can contain multiple repositories (Repository); each repository can contain multiple tags (Tag); each tag corresponds to an image.
Usually, a repository will contain images of different versions of the same software, and tags are often used for each version of the software. We can specify the image of which version of this software through the format of <warehouse name>:<label>. If no label is given, latest will be used as the default label.
Take the Ubuntu image as an example, ubuntu is the name of the repository, which contains different version labels, eg, 14.04, 16.04. We can specify which version of the image is required through ubuntu:14.04, or ubuntu:16.04. If the tag is omitted, such as ubuntu, it will be treated as ubuntu:latest.
Repository names often appear in the form of two-segment paths, 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 and depends on the specific Docker Registry software or service used.
Docker Registry exposes services
The Docker Registry public service is a registry service that is open to users and allows users to manage images. Generally, such public services allow users to upload and download public images for free, and may provide paid services for users to manage private images.
The most commonly used Registry public service is the official Docker Hub, which is also the default Registry and has a large number of high-quality official images. In addition, there is CoreOS's Quay.io, where CoreOS-related images are stored; Google's Google Container Registry, Kubernetes' images use this service.
Accessing these services within the country may be slower for a number of reasons. Some domestic cloud service providers provide Registry Mirror for Docker Hub, and these mirror services are called accelerators. Common ones are Alibaba Cloud Accelerator, DaoCloud Accelerator, etc. Using the accelerator will download the Docker Hub image directly from the domestic address, which will be much faster than downloading directly from Docker Hub. There is a detailed configuration method in the Installing Docker section.
There are also some cloud service providers in China that provide public services similar to Docker Hub. For example, Speed Cloud Mirror Warehouse, NetEase Cloud Mirror Service, DaoCloud Mirror Market, Alibaba Cloud Mirror Library, etc.
Private Docker Registry
In addition to using public services, users can also build private Docker Registry locally. Docker officially provides the Docker Registry image, which can be used directly as a private Registry service. In the Private Repository section, there will be further explanations on building a private Registry service.
The open source Docker Registry image only provides the server-side implementation of the Docker Registry API, which is sufficient to support docker commands without affecting usage. It does not include a graphical interface, as well as advanced functions such as image maintenance, user management, and access control. These advanced features are available in the official commercial version of the Docker Trusted Registry.
In addition to the official Docker Registry, there are third-party software that implements the Docker Registry API and even provides a user interface as well as some advanced features. For example, VMWare Harbor and Sonatype Nexus.