Docker source code analysis (1): Docker architecture

Label cloud computingDockerframework
5996 people read comment(0) Collection report

1 background

1.1 Docker profile

Docker is an open source Docker company based on lightweight virtualization technology container engine project, the entire project is based on the Go language development, and to comply with the Apache 2 agreement. Currently, Docker can quickly automate the deployment of the container application, and can be used by the kernel virtualization technology (namespaces and cgroups, etc.) to provide the container's resource isolation and security, etc.. Due to the isolation docker through the operating system level virtualization implementations, so docker container at run time, do not need to similar virtual machine (VM) additional cost of operating system, improve the utilization rate of resources, and improve the performance such as io.

Due to open many new characteristics and the project itself and docker in less than two years time is rapidly gaining the favor of many manufacturers, which is including Google, Microsoft, VMware and other industry leaders.Google launched in June this year, Kubernetes, to provide Docker container scheduling services, and in August this yearMicrosoft announced support for Azure on KubernetesThenTraditional virtualization giant VMware announced strong cooperation with Docker. Mid September of this year,Docker is to get $40 million C round of financing, in order to promote the development of distributed applications.

Judging from the current situation, the prospect of Docker is excellent. This series of articles from the source point of view, detailing the structure of the Docker, Docker and the operation of the Docker excellence. This article is the first Docker source analysis series - Docker architecture.

1.2 Docker version information

In this paper, the analysis of the Docker architecture is based on the Docker source code and the corresponding version of the Docker operating results, which Docker for the latest version 1.2.

2 Docker architecture analysis content arrangement

The purpose of this paper is: to understand the Docker source code, based on the analysis of the Docker architecture. The process of analysis is mainly carried out according to the following three steps:

* Docker total frame composition display
* analysis of function and implementation of each module in Docker architecture diagram
* take the execution of the Docker command as an example, to explain the operation process of Docker.

3 Docker total architecture diagram

Learning Docker source code is not a boring process, but you can understand the design principles of Docker architecture. Docker in terms of users is a C / S mode of architecture, and at the rear end of the docker is a very loosely coupled architecture, module to carry out their duties, and organic combinations, docker support operation.

In this, the first Docker total structure, as shown in figure 3.1.

Figure 3.1 Docker total architecture

As shown in Figure 3.1, it is not difficult to see that the user is using Client Docker to establish communication with Daemon Docker, and send the request to the latter.

And docker daemon as part the docker architecture. First, provide the server function so that it can accept docker client's request; and engine execution within the docker a series of work, each are in the form of a job.

In the running process of the job, when the container image, from the docker registry download mirror, and the image management driven graphdriver will download the image is stored as a graph; when the network environment need to be created as a docker, through the network management driven networkdriver create and configure the docker container network environment; when the need to limit docker container resources to run or execute an instruction from the user operation, is through the execdriver to complete.

And libcontainer is an independent container management package, networkdriver and execdriver are through the libcontainer to achieve the specific operation of the container.

After executing the command of the running container, an actual Docker container is in the running state, the container has an independent file system, independent and safe operation environment, etc..

The function and implementation of each module in the 4 Docker architecture

Next, we will start with the Docker total frame composition, pumping out the various modules within the framework, and the various modules for a more detailed analysis of the structure and function of the. The main modules are: Client Docker, Daemon Docker, Registry Docker, Graph, Driver, libcontainer, and container Docker.

4.1 Client Docker

Client Docker is a client for Docker architecture to build communication with Daemon Docker. The user can use the executable file for the docker, through the docker command line tool can initiate a large number of management container request.

Client Docker can be established by the following three ways: tcp://host:port, unix://path_to_socket, Daemon and Docker. For the sake of simplicity, this article will use the first method as a prototype for the communication between the two. At the same time, with the docker daemon establishes a connection and transmission request, the docker client can be set through the command line flags parameter set security transmission layer protocol (TLS) parameters, to ensure the safety of the transmission.

Docker client container management request, the docker daemon accepts requests and processes, when docker client receives the return and the corresponding simple processing of the request, docker client a complete life cycle ends. When you need to continue to send the container management request, the user must once again through the docker executable file to create Client Docker.

4.2 Daemon Docker

Daemon Docker is a resident in the Docker architecture in the background of the system process, the function is: to accept and handle the request Client Docker. The process in the background to start a Server, Server is responsible for receiving Client Docker send the request; after receiving the request, Server through routing and distribution scheduling, find the corresponding Handler to perform the request.

Daemon Docker to start the use of the executable file is docker, and Client Docker to start using the same executable file docker. When the docker command is executed, the Daemon Docker and Client Docker are distinguished by the incoming parameters.

Daemon Docker architecture, can be roughly divided into the following three parts: Server Engine, Docker and Job. Daemon architecture as shown in figure 4.1.

Fig. 4.1 schematic diagram of Daemon Docker architecture

Docker Server 4.2.1

Server Docker in the Docker architecture is specifically designed to serve Client server Docker. The server function is: accept and dispatch the request to distribute Client Docker. The architecture of Server Docker is shown in Figure 4.2.

Fig. 4.2 schematic diagram of Server Docker architecture

During the startup of Docker, a mux.Router is created through the package gorilla/mux, which provides the requested routing function. In gorilla/mux, Golang is a powerful URL router as well as a dispatching distributor. The mux.Router adds a large number of routing entries, each of which is composed of a HTTP request method (PUT, POST, DELETE, or GET), URL, and Handler three parts.

If the docker client through HTTP access docker daemon, created after mux.Router. Docker will server listener address and mux.Router as parameters, to create a httpSrv=http.Server{}, final implementation httpSrv.Serve () to request the service.

In the process of Server service, Server on the listener to accept Client Docker access request, and create a new goroutine to service the request. In a goroutine first read in request content, and analytical work, then find the corresponding routing, then call the corresponding handler to handle the request, the handler to finish processing the request reply to the request.

Need to pay attention to: Server Docker running in the Docker startup process, is to rely on a named "job" of the serveapi to complete the operation. In principle, the docker server operation is many job in a, but to emphasize the importance of docker server and for the important characteristics of the follow-up job services, the "serveapi" of the job alone pumping out of the analysis, understood as a docker server.

Engine 4.2.2

Engine is the Docker architecture in the running engine, while also running the core module Docker. It plays the role of the container Docker storage warehouse, and manages the management of these containers by performing job.

In the design and implementation of Engine data structure, there is a handler object. The handler objects are stored on a number of specific handler job processing access. For example, handler Engine object has one for: {"create": daemon.ContainerCreate,}, then that when the name "create" job in the run, the implementation of the handler daemon.ContainerCreate.

Job 4.2.3

A Job can be considered as the most basic work execution unit within the Engine architecture of Docker. Docker can do every job, can be abstracted as a job. For example: a process is running in the interior of the container, which is a job; to create a new container, which is a job, a document downloaded from the Internet, this is a job; including before in docker server said, creating service server to the HTTP API, which is a job, and so on.

Job designers, the Job design process is similar to the Unix process. For example: Job has a name, there are parameters, there are environmental variables, there is a standard input and output, there are errors, there is a return to the state, etc..

4.3 Registry Docker

Registry Docker is a repository of storage containers. Container mirroring is the document schema and directory that is loaded to initialize the container when the container is created.

In the running process of the docker and docker daemon will communicate with the docker registry, and realize the mirror image search, image download, upload an image of three functions, corresponding to the three functional job name were "search", "pull" and "push".

Among them, in the Docker architecture, Docker can use public Registry Docker, which is known as the Hub Docker, so that Docker access to the container image files, you must access through the InternetDocker HubAt the same time, Docker also allows the user to build a local private Registry Docker, so that the image of the container can be guaranteed to be completed within the network.

4.4 Graph

Graph plays the role of the storage in the Docker architecture, as well as the record of the relationship between the downloaded container mirror image. On the one hand, Graph stores a local version of the information file system image, on the other hand, through the GraphDB records all the file system mirror the relationship between each other. The architecture of Graph is shown in figure 4.3.

Fig. 4.3 schematic diagram of Graph architecture

Among them, GraphDB is a small map database built on top of SQLite, which implements the naming of nodes and the relationship between the nodes. It implements only a small subset of most graph databases, but provides a simple interface that represents the relationship between nodes.

At the same time in a local directory for the graph, on every container mirror, specific storage information is: the metadata of the image of the container, container image size information, and represented by the image of the container specific rootfs.

4.5 Driver

Driver is the driver module in the Docker architecture. Through the Driver driver, Docker can be implemented on the Docker container execution environment. Due to the life cycle of the Docker operation, not all of the operations of the user are for the management of the Docker container, in addition to the information on the operation of Docker access, Graph storage and records, etc.. Therefore, in order to separate the management of the Docker container from the Daemon Docker internal business logic, the Driver layer driver is designed to take over all of this part of the request.

In the realization of Driver Docker, can be divided into the following three categories: graphdriver, networkdriver and execdriver.

Graphdriver is mainly used to complete the management of container image, including storage and access. That when users need to download the specified container mirror, graphdriver will container image storage in the specified local directory; at the same time when users need to use the specified container image to create the container rootfs, graphdriver from local mirror storage directory get specified container mirror like.

Before the graphdriver initialization process, there are 4 kinds of file system or class file system in its internal registration, they are aufs, Btrfs, VFS and devmapper. And Docker at the time of initialization, by obtaining the system environment variable "DOCKER_DRIVER" to extract the specified type of the use of driver. And after all the graph operation, the use of the driver to perform.

The architecture of graphdriver is shown in figure 4.4:

Fig. 4.4 schematic diagram of graphdriver architecture

Docker container network environment configuration is completed, including start docker docker environment create a bridge networkdriver use; docker container created to create exclusive virtual network device; and docker container allocation of IP, port, and with the host do port mapping, set container firewall policy etc.. The architecture of networkdriver is shown in figure 4.5:

Fig. 4.5 schematic diagram of networkdriver architecture

Docker as the execdriver container execution driven, responsible for the creation of the container run namespace, responsible for the statistics and restrictions on the use of container resources, responsible for the actual operation of the internal process of containers, etc.. In the implementation process of execdriver, the original can be used to call the LXC driver LXC interface, to control the configuration of the container as well as the life cycle, and now the default execdriver use native drive, do not rely on LXC. Embodied in the Daemon startup process load the ExecDriverflag parameters, the parameters in the configuration file has been set to native". This can be considered a big change in the 1.2 version of the Docker, or Docker to achieve a threatened cross platform. Execdriver architecture as shown in figure 4.6:

Fig. 4.6 schematic diagram of execdriver architecture

4.6 libcontainer

Docker is a libcontainer architecture in the use of Go language design and implementation of the library, the design is to hope that the library can not rely on any dependence, direct access to the kernel and the container related API.

It is because of the existence of Docker, libcontainer can directly call libcontainer, and the final control of the container namespace, cgroups, AppArmor, network equipment, as well as the rules of the firewall. The completion of this series of operations do not need to rely on LXC or other packages. Libcontainer architecture as shown in figure 4.7:

Fig. 4.7 schematic diagram of libcontainer

In addition, libcontainer provides a set of standard interfaces to meet the requirements of the upper layer for container management. Or, libcontainer shielded the Docker upper layer of the container's direct management. And due to the libcontainer using the go this cross platform language development to achieve and, in turn, may be accessed by multiple upper layer of different programming languages, so it is hard to say, future docker will tightly and Linux bundled together. While at the same time, Azure in its famous cloud computing platform Microsoft, also added support for Docker, the degree of openness of the industry and the industry's fiery degree Docker.

Don't talk docker, due to libcontainer and itself and the system of loose coupling characteristics, is likely to in other container for the prototype of the platform, but also may hasten the birth of cloud computing in the field of new projects.

4.7 container Docker

Container Docker (Docker container) is the final embodiment of service delivery in the Docker architecture.

Docker according to the needs of users and instructions, ordered the corresponding Docker container:

* the user can customize the rootfs and other file systems by specifying the container mirroring;
* the user makes the Docker container using the specified computing resource by specifying the quota for the computing resource;
* users through the configuration of the network and its security policy, so that the Docker container has an independent and secure network environment;
* the user performs the specified job by specifying the run command to make the Docker container.

The schematic diagram of the Docker container is shown in figure 4.8:

Fig. 4.8 schematic diagram of Docker container

5 Docker operation case analysis

The last chapter focuses on the introduction of the various parts of the Docker architecture. The contents of this chapter will be based on a series of Docker modules to brief analysis, analysis of the prototype for the docker pull docker and run Docker two commands.

5.1 pull docker

The role of the pull docker command is to download the specified container image from the Registry Docker and store it in the local Graph to prepare for the subsequent creation of the Docker container. Pull docker command execution process as shown in figure 5.1.

Fig. 5.1 schematic diagram of pull docker command execution process

As shown in the figure, the red arrow marked in the graph indicates that the pull docker command is initiated, and the Docker is running a series of operations. One by one analysis of these steps.

(1) Client docker accepts pull Docker command, after analyzing the request and the collection of the request parameters, send a HTTP request to Server Docker, HTTP request method for POST, request /images/create for "URL" + "XXX"";

(2) Server Docker accepts the above HTTP request, and hand over to mux.Router, mux.Router through URL and request method to determine the implementation of the request of the specific handler;

(3) mux.Router will request routing distribution to the corresponding handler, specific to PostImagesCreate;

(4) in the PostImageCreate of the handler, a pull called "job" was created and started to perform;

(5) the "pull" of the job in the implementation process, the implementation of the pullRepository operation, that is, from the Registry Docker to download the corresponding one or more image;

(6) named "pull" job will download the image to the graphdriver;

(7) graphdriver is responsible for the storage of image, one party to create graph objects, on the other hand in the relationship between image records GraphDB.

5.2 run docker

The role of the run docker command is to run an instruction within a completely new Docker container. Docker in the implementation of this order, the work can be divided into two parts: first, to create the Docker container required rootfs; second, to create a network of containers and other operating environment, and the actual operation of the user instructions. Therefore, in the entire implementation process, Client Docker to Server Docker to send a two HTTP request, the second request is initiated by the first request to return the state. Docker Run command execution process as shown in figure 5.2.

Fig. 5.2 schematic diagram of run docker command execution process

As shown in the figure, the red arrow marked in the graph indicates that the run docker command is initiated, and the Docker is running a series of operations. One by one analysis of these steps.

(1) after docker client accept docker the run command to and analysis after the request and collected after the request parameters and send an HTTP request to docker server, HTTP request method is post, the request URL as "/containers/create? + the XXX;

(2) Server Docker accepts the above HTTP request, and hand over to mux.Router, mux.Router through URL and request method to determine the implementation of the request of the specific handler;

(3) mux.Router will request routing distribution to the corresponding handler, specific to PostContainersCreate;

(4) in the PostImageCreate of this handler, a named "job" create was created, and began to make the job run;

(5) called "create" job in the running process, the implementation of the Container.Create operation, the operation needs to obtain the container image to create a Docker for the rootfs container, that is called graphdriver;

(6) graphdriver from Graph to get all the mirrors that are needed to create the Docker container rootfs;

(7) graphdriver will rootfs all images, loaded into the Docker container specified file directory;

(8) if the above operations are all normal, no return error or exception, then Client Docker received Server Docker return state, initiated the second HTTP request. Request method for "POST", request /containers/ for "+container_ID+" /start "URL"";

(9) Server Docker accepts the above HTTP request, and hand over to mux.Router, mux.Router through URL and request method to determine the implementation of the request of the specific handler;

(10) mux.Router will request routing distribution to the corresponding handler, specific to PostContainersStart;

(11) in the PostContainersStart of this handler, called "job" start was created and started to perform;

(12) a start named "job" after the implementation of the initial configuration of the work, began to configure and create a network environment, call networkdriver;

(13) networkdriver needs to create a network interface device for the specified Docker container, and assign it to IP, port, and set firewall rules, and the corresponding operation is referred to the netlink package in libcontainer;

(14) netlink completion of the Docker container network environment configuration and creation;

(15) to return to the name "start" of the job, after the implementation of some of the auxiliary operations, job began to execute the user instructions, call execdriver;

(16) execdriver is called to initialize the Docker container internal running environment, such as namespace, resource control and isolation, as well as the execution of the user commands, the corresponding operation to libcontainer to complete;

(17) libcontainer is called to complete the operation environment within the Docker container initialization, and the final implementation of the user requirements to start the command.

6 Summary

The from docker 1.2 source of analysis and abstract docker's chart, and each module in the architecture diagram of function and analysis of the implementation, the two docker command shows the docker's internal operation.

Through the study of Docker architecture, we can comprehensively deepen the understanding of Docker design, function and value. At the same time in the use of Docker to achieve the user customized distributed system, but also to better find the existing platform and Docker more ideal fit point. In addition, familiar with the existing Docker architecture and design ideas, but also can bring more inspiration to the field of cloud computing PaaS, gave birth to more practice and innovation.

7 introduction of the author

Sun Hongliang,DaoCloudNew team members, software engineers, Zhejiang University computer science graduates.

Graduate school during active in PAAS and docker open source community, in-depth study and enrich the practice of cloud foundry, good at analysis of the underlying platform code, on the platform of the distributed architecture has some experience, has written a lot of depth technology blog.

At the end of 2014 to join the DaoCloud partner to join the team, committed to the spread of Docker based container technology, to promote the pace of the application of the Internet in the container.

Welcome to exchange,

8 references

[Docker (software) Wikipedia] -From [Docker Architecture]
Libcontainer [Docker]
[simple Docker (1): Docker core technology preview]
0.9: introducing execution drivers and [Docker libcontainer]
Lost packages of docker] [The

Welcome to pay attention to the Docker source code analysis of the public number

step on
Guess you're looking for
View comments
* the above user comments only represent their personal views, does not represent the views or position of the CSDN website
    personal data
    • Visit85395 times
    • Integral:One thousand three hundred and sixty-three
    • Grade
    • Rank:18401st name
    • Original47
    • Reproduced:0
    • Translation:1
    • Comments:50
    Blog column
    Contact information
    Latest comments