table of Contents
Article Directory
The composition of the container engine
First, take CNCF's containerd container engine as an example to describe the general composition of the container engine.
If you divide it into the left and right sides in the figure above, you can think that containerd provides two major functions.
- runtime , which is the management of the container life cycle.
- storage , that is, the management of a mirrored storage.
According to the level of view:
- The first layer is GRPC. For the upper layer, containerd provides services to the upper layer in the form of GRPC serve. Metrics This part mainly provides some content of cgroup Metrics;
- The left side of the lower layer is a storage of container images, the middle is images, containers, and the bottom is Metadata. This part of Metadata is stored on the disk through bootfs. The Tasks on the right is the container structure of the management container. Events means that some operations on the container will have an Event sent to the upper layer, and then the upper layer can subscribe to this Event, thereby knowing what changes have occurred in the container state;
- The bottom layer is the Runtimes layer. This Runtimes can be distinguished by type, such as runC or kata container.
Docker components
Docker's software architecture includes:
- Docker Client : Initiate a request to the Docker Server process, such as build, pull, run and other operations. Docker Client can access both the local daemon (local host) process and the remote (remote host) daemon process.
- Docker Server : Listen to REST API requests and manage Docker objects, such as images, containers, networks, and volumes. The daemon can also communicate with other daemons to manage Docker services.
- Docker Registry (registry, warehouse registration server) : a central warehouse that stores Docker Images. Among them, Docker Hub is a Public Registry that anyone can use. The default configuration of Docker Server is to find Images on Docker Hub. Individuals can also run Private Registry. If Docker DataCenter is used, it includes Docker Trusted Registry (DTR). When using the docker pull or docker run command, the required Image will be extracted from the Registry configured by Docker Server.
Note that there is a difference between the Repository and the Registry. There are often multiple Repositories stored on the Registry, and each Repository contains multiple Images, and each Image has a different Tag.
Docker's software architecture
As can be seen from the above figure, the main modules of Docker are:
- Docker Client
- Docker Daemon
- Docker Registry
- Graph
- Driver
- Libcontainer
- Docker Container
Users use Client to establish communication with Daemon and send requests to the latter. Daemon, as the core of Docker, first provides Server to accept Client's requests, and then executes a series of tasks within Docker through Engine. Each task is based on a Job. The existence of form.
- When it is necessary to provide an Image for the Container, download the image from the Registry, and use the image management to drive Graphdriver to store the downloaded image in the form of Graph;
- When you need to create a network environment for the Container, create and configure the Container network environment through the network management driver Networkdriver;
- When it is necessary to limit running resources or execute user instructions for the Container, it is done through Execdriver.
Libcontainer is an independent Container management module. Both Networkdriver and Execdriver use Libcontainer to complete the operations on the Container. After a series of tasks of docker run are executed, an actual Container is in a running state. The Container has an independent file system, an independent and safe operating environment, etc.
Docker Client
Docker Client appears as a docker executable file on Linux. After the Client receives the response returned by Daemon and performs simple processing, a complete life cycle of the Client is over. Client can establish communication with Daemon in 3 ways:
- tcp://host:port
- unix:path_to_socket;fd://socketfd
- Set up TLS connection by setting command line parameters
Docker Daemon
Docker Daemon appears as a system process that resides in the background on Linux and can be managed by systemd. In fact, it is the same docker executable file as Docker Client.
Docker Daemon can be subdivided into the following modules:
- API Server : Daemon will start a Docker Server in the background. It is an API Server based on Golang's Gorilla/Mux package. It accepts requests sent by Clients and routes them to different Handlers for processing.
It is worth noting that the startup of Docker Server is done by running a Job named serveapi. So the essence of Server is one of many Jobs.
-
Engine : It is the running engine of Docker. It plays the role of Docker Container storage warehouse and manipulates and manages these containers by executing Job. Docker Engine has two different versions: Docker Engine Enterprise (Enterprise Edition) and Docker Engine Community (Community Edition).
-
Job : A Job can be considered as the most basic work execution unit within the Engine. Every work done by Docker can be abstracted into a Job. For example: run a process inside the container, this is a job; create a new container, this is a job, download a document from the Internet, this is a job, and so on. The designer of Job designed Job to be similar to Unix Processor. For example: Job has a name, parameters, environment variables, standard input and output, error handling, and return status.
Docker Registry
Docker Registry is a repository for storing Images. During the operation of Docker, Daemon will communicate with the Registry and implement three functions: search for mirrors, download mirrors, and upload mirrors. The jobs corresponding to these three functions are search, pul, and push.
Docker can use the public Docker Registry, namely: Docker Hub, from which you can find Docker images from open source projects, software vendors, and even personal accounts. At the same time, Docker also allows users to build a local private Docker Registry, which can ensure that the acquisition of container images is completed on the intranet.
Graph
Graph acts as the custodian of the downloaded mirrors and the recorder of the relationship between the downloaded mirrors. On the one hand, Graph stores local file system mirrors with version information, and on the other hand, it also records the relationship between all file system mirrors through GraphDB.
Among them, GraphDB is a small graph database built on SQLite, which implements the naming of nodes and the recording of the relationship between nodes. It only implements a small subset of most graph databases, but provides a simple interface to represent the relationship between nodes.
At the same time, in the local directory of Graph, about each container image, the specific information stored is: the metadata of the container image, the size information of the container image, and the specific Rootfs represented by the container image.
Driver
Driver is the driver module, and Docker uses Driver to customize the execution environment of the Container. Can be divided into the following three types of drivers:
- Graphdriver
- Networkdriver
- Execdriver
Graphdriver
Graphdriver is used to complete Image management, including storage and retrieval. When the user needs to download the specified image, Graphdriver will store the image in the specified local directory; when the user needs to use the specified image to create the Rootfs of the container, Graphdriver will obtain the specified container image from the local image storage directory.
Before Graphdriver is initialized, there are 4 kinds of file systems or file-like systems registered in it. They are:
- Onto
- Btrfs
- Vfs
- Devmapper
When Graphdriver is initialized, it obtains the system environment variable DOCKER_DRIVER to extract the specified type of Driver used. All subsequent Graph operations are executed using this Driver.
The architecture of Graphdriver is as follows:
Networkdriver
Networkdriver is used to complete the configuration of the Container network environment, including:
- Create Bridge for Docker deamon when it starts;
- Create a dedicated virtual network card device for the Container when it is created, assign IP and Port to the Container, and do port mapping with the host, and set the container firewall policy.
The architecture of Networkdriver is as follows:
Execdriver
As the execution driver of the Container, Execdriver is responsible for creating the Container runtime namespace, responsible for the statistics and restrictions of container resource usage, and responsible for the actual operation of the internal processes of the container.
In the early implementation of Execdriver, LXC Driver was used to call the interface of LXC to manipulate the configuration and life cycle of the container. Now Execdriver uses the Native driver by default and no longer depends on LXC. It can be selected by specifying the ExecDriverflag parameter when starting Daemon. The default is native.
The Execdriver architecture is as follows:
Libcontainer
Libcontainer is a library implemented in Golang in the Docker architecture. The original intention of the design is that the library can directly access the container-related APIs in the Kernel without relying on any dependencies.
It is precisely because of the existence of Libcontainer that Docker can finally manipulate the Namespace, Cgroups, Apparmor, network equipment and firewall rules of the Container. The completion of this series of operations does not need to rely on LXC or other libraries.
Libcontainer architecture is as follows:
Docker strips out the underlying container runtime to achieve better platform independence. LibContainer is an abstraction of various containers, developed into RunC, and contributed to the OCP organization as a standard for defining the container environment.
Docker Container
Docker Container becomes a container process running on the Linux operating system, which is the final form of Docker service delivery.
- The user can specify the Image so that the Container can customize the file system such as Rootfs.
- The user specifies the quota of computing resources to enable the Container to use the specified computing resources.
- The user configures the network and its security policies to enable the Container to have an independent and secure network environment.
- The user makes the Container perform the specified work by specifying the command to be run.
