Docker core concepts
Mirroring
What is mirroring? In layman's terms, it is a read-only file and folder combination. It contains all the basic files and configuration information needed when the container is running, and is the basis for container startup. So if you want to start a container, you must first have a mirror.
Mirroring is a prerequisite for Docker container startup.
If you want to use a mirror, you can use these two ways:
1. Create a mirror by yourself.
Usually, an image is built based on a basic image, and you can add some user-defined content to the basic image.
For example: you can make your own business image based on the centos image, first install the nginx service, then deploy your application, and finally do some custom configuration, so that a business image of your own is ready.
2. Pull the mirror images made by others from the functional mirror warehouse.
Some commonly used software or systems will have official images.
For example: nginx, ubuntu, centos, mysql, etc. You can go to Docker Hub to search and download them.
container
What is a container?
Containers are another core concept of Docker. In layman's terms, the container is the running entity of the image.
The image is a static read-only file, and the container has a writable file layer required at runtime, and the process in the container is in a running state. That is, the container is running the real application process.
The container has five states: initial creation, running, stopping, suspending and deleting.
Although the essence of a container is a process running on the host, the container has its own independent namespace isolation and resource restrictions. That is to say, inside the container, you cannot see the process, environment variables, network and other information on the host. This is the essential difference between the container and the process directly running on the host.
warehouse
Docker's mirror warehouse is similar to a code warehouse, used to store and distribute Docker images. The mirror warehouse is divided into public mirror warehouse and private mirror warehouse.
At present, Docker Hub (https://hub.docker.com/) is the official public mirror repository of Docker. It not only has many official mirrors of applications or operating systems, but also many mirrors developed by organizations or individuals for us to store for free, Download, research and use. In addition to the public mirror repository, you can also build your own private mirror repository.
The connection between mirror, container, and warehouse is shown in the following figure:

As can be seen from the above figure, the image is the cornerstone of the container, and the container is created by the image. One image can create multiple containers, and the container is the entity that the image runs on. The warehouse is used to store and distribute images.
Docker's core architecture
Before understanding the core architecture of Docker, let's briefly introduce the history of container development.
Docker became an instant hit in 2013, and has continued to arouse excitement in the IT world since then and has become synonymous with container technology. But at this time, in addition to Docker containers, there are many other container technologies on the market, such as CoreOS's rkt, lxc, etc.
In addition to launching its own container software rkt, the CoreOS team has also crafted a lightweight operating system based on the Linux kernel. Similar to the open source project Docker, rkt is a container running version that allows container creation.
The emergence of so many container technologies will inevitably produce some problems. For example, what is the standard for container technology? Who should make container standards?
Perhaps most people will say that Docker has become the benchmark for container technology. Isn't it good to regard Docker as the standard for container technology? The fact is not as simple as imagined. Because at that time there was not only a dispute over container standards, but also a fierce dispute over orchestration technology. At that time, there were three main forces of orchestration technology, namely Docker Swarm, Kubernetes and Mesos.
Swarm is undoubtedly willing to use Docker as the only container runtime, but Kubernetes and Mesos disagree, because they don't want to be too single in the form of scheduling.
In this context, the container war finally broke out, and OCI also emerged in this context.
The full name of OCI is the Open Container Initiative (Open Container Initiative) , which is a lightweight and open governance structure. With the strong support of the Linux Foundation, the OCI organization was formally registered and established in June 2015. The foundation aims to develop an open container standard for users around the format and image runtime of industrialized containers.
At present, there are mainly two standard documents: the container runtime standard (runtime spec) and the container image standard (image spec).
It is precisely because of the container war that Docker had to change some technical architecture during the war. Finally formed the technical architecture shown in the figure below.

We can see that the overall architecture of Docker adopts the C/S (Client/Server) model , which is mainly composed of two parts: the client and the server.
The client is responsible for sending operation instructions, and the server is responsible for receiving and processing instructions. There are many ways to communicate between the client and the server, either through UNIX sockets on the same machine, or remote communication through a network connection.
The following is an introduction to the client and server.
Docker client
Docker client is actually a general term. The docker command is the main way for Docker users to interact with the Docker server.
In addition to using the docker command, you can also directly request the REST API to interact with the Docker server, and you can even use SDKs in various languages to interact with the Docker server. At present, the community maintains SDKs in dozens of languages such as Go, Java, Python, PHP, etc., which are sufficient to meet everyone's daily needs.
Docker server
Docker server is the collective name for all Docker background services. Among them, dockerd is a very important background management process, which is responsible for responding to and processing requests from the Docker client, and then converting the client's request into a specific operation of Docker.
For example: the operation and management of specific objects such as mirrors, containers, networks, and mounted volumes.
Since the birth of Docker, the server has undergone many restructurings. At first, the components of the server were all integrated in the docker binary. But since version 1.11, dockerd has become an independent binary. At this time, the container is not directly started by dockerd, but integrates multiple components such as containerd and runC.
Although Docker's architecture is constantly being refactored, the basic functions and positioning of each module have not changed. It is the same as a general C/S architecture system. The Docker server-side module is responsible for interacting with the Docker client and managing Docker's resources such as containers, images, and networks.
Docker important components
Docker has two vital components: runC and containerd.
runC is an official implementation of Docker according to the OCI container runtime standard. In layman's terms, runC is a lightweight tool used to run containers, and it is really used to run containers.
Containerd is a core component of the Docker server. It is stripped from dockerd. Its birth completely follows the OCI standard and is the product of container standardization. Containerd starts and manages runC through containerd-shim. It can be said that containerd really manages the life cycle of the container.
As can be seen from Figure 3, dockerd communicates with containerd through gRPC. Because dockerd is running with a real container, there is an OCI standard layer of containerd in the middle of runC, so that dockerd can ensure that the interface is backward compatible.
gRPC is a remote service call. For more information, please refer to https://grpc.io
containerd-shim which means a washer, which is similar to a washer sandwiched between a screw and a nut when screwing a screw.
The main function of containerd-shim is to decouple containerd from the real container process, and use containerd-shim as the parent process of the container process, so that restarting dockerd does not affect the already started container process.
After understanding the relationship between dockerd, containerd, and runC, you can start a Docker container to verify the relationship between their processes.
The relationship between Docker components
Take version 18.09.2 of Docker as an example (if the following command does not output the expected result when executed, it may be a problem with the Docker version):
First, start a docker101tutorial container with the following command:
$ docker run -d docker101tutorial sleep 5000After the container is started, check the PID of dockerd with the following command:
$ sudo ps aux |grep dockerd
root 4247 0.3 0.2 1447892 83236 ? Ssl Jul09 245:59 /usr/bin/dockerdFrom the above output, we can know that the PID of dockerd is 4247. In order to verify the calling relationship between the Docker components in the above figure, use the pstree command to check the process parent-child relationship:
$ sudo pstree -l -a -A 4247
dockerd
|-containerd --config /var/run/docker/containerd/containerd.toml --log-level info
| |-containerd-shim -namespace moby -workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/d14d20507073e5743e607efd616571c834f1a914f903db6279b8de4b5ba3a45a -address /var/run/docker/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
| | |-sleep 5000In fact, when dockerd starts, containerd is started, and dockerd and containerd always exist.
When executing the docker run command (create and start the container through the docker101tutorial image), containerd will create containerd-shim to act as a "shim" process, and then start the real process sleep 5000 of the container. From this it appears that this process is completely consistent with the architecture diagram.
The above content is all that is shared today. You need to master the core design concepts of Docker architecture: the principle of mirroring, containers, and warehouses in order to better use and use Docker.
Welcome to pay attention to [The Way of Infinite Testing] public account , reply [receive resources],
Python programming learning resources dry goods,
Python+Appium framework APP UI automation,
Python+Selenium framework Web UI automation,
Python+Unittest framework API automation,
Resources and codes are sent for free~
There is a QR code of the official account at the bottom of the article, you can just scan it on WeChat and follow it.
Remarks: My personal public account has been officially opened, dedicated to the sharing of test technology, including: big data testing, functional testing, test development, API interface automation, test operation and maintenance, UI automation testing, etc., WeChat search public account: "Infinite The Way of Testing", or scan the QR code below:
Add attention and let us grow together!