Docker overall architecture diagram

Docker is a C/S architecture, and the back end is a loosely coupled architecture, with each module doing its own job.

  1. Users communicate with the Docker Daemon using the Docker Client and send requests to the Docker Daemon.

  2. As the main part of Docker architecture, Docker Daemon first provides functions of Docker Server so that it can accept requests from Docker Client.

  3. Docker Engine performs a series of internal Docker jobs, each in the form of a Job.

  4. In the running process of Job, when the container image is needed, the image is downloaded from Docker Registry and stored in the form of Graph through the image management driver Graphdriver.

  5. When you need to create a network environment for Docker, create and configure a Docker container network environment through the network management driver Networkdriver.

  6. When you need to restrict the Docker container from running resources or executing user commands, use Execdriver to do so.

  7. Libcontainer is an independent container management package. Networkdriver and Execdriver use Libcontainer to perform operations on containers.

Docker module components analysis

Docker Client “initiate requests”

  1. Docker Client is a Client that communicates with the Docker Daemon. The executable file used by users is docker (a command line executable file), and the docker command uses the form of the following parameters to realize a complete request command (for example, docker images, where the command is immutable, images, where the parameters are variable).

  2. The Docker Client can communicate with the Docker Daemon through TCP ://host:port, Unix ://path_to_socket, and fd://socketfd

  3. After the Docker Client sends the container-managed request, the Docker Daemon receives and processes the request. When the Docker Client receives the returned request and simply processes it, the complete life cycle of the Docker Client ends. (A complete request: send the request → process the request → return the result), is not different from the traditional C/S architecture request process.

Docker Daemon Daemon

  1. Docker Daemon architecture diagram



Docker Server “Dispatch request”

  • Docker Server architecture diagram


  • Docker Server is the Server side of THE C/S architecture. Function to accept and dispatch Docker Client sent requests. After receiving the request, Docker Server finds the corresponding Handler to execute the request through routing and distribution scheduling.

  • During the startup of Docker, a mux.Router is created from the gorilla/mux package to provide routing for requests. Gorilla/MUx in Golang is a powerful URL router and dispatch dispatcher. The Mux. Router adds many routing entries. Each route entry consists of HTTP request methods (PUT, POST, GET, or DELETE), URL, and Handler.

  • After creating the mux.router, Docker takes the Server’s listening address and mux.router as parameters to create an httpSrv= http.server {}, and finally executes httpsrv.serve () for the request.

  • In the Docker Server service process, the Docker Server receives the Docker Client access request in the listener, and creates a new Goroutine to serve the request. In Goroutine, the request is read and parsed, then the appropriate routing item is found and the appropriate Handler is called to process the request, and finally the Handler processes the request and replies to the request.

3. Docker Engine

  • Docker Engine is the running Engine in Docker architecture, and also the core module of Docker running. It acts as a repository for Docker Containers and manages them by performing jobs.

  • In the design and implementation of Docker Engine data structure, there is a Handler object. This Handler object stores access to Handler handling for a number of specific jobs. Docker Engine Handler {” create “: Daemon. ContainerCreate,} indicates that when the Job named daemon.ContainerCreate is running, the Handler of daemon.ContainerCreate is executed.

4. Job

  • A Job can be considered as the most basic work execution unit of Docker Engine in Docker architecture. Every Job that Docker can do can be abstracted as a Job. For example, running a process inside a container is a Job; Create a new container, which is a Job. The running process of Docker Server is also a Job named ServeApi.

  • Job designers designed Jobs to resemble Unix processes. For example, a Job has a name, parameters, environment variables, standard input and output, error handling, and return status.

Docker Registry

  1. Docker Registry is a repository (Registry) that stores container images, which can be understood as a cloud image repository. Docker pull uses [Repository]:[tag] to define a specific Image.

  2. During the running of Docker, Docker Daemon communicates with Docker Registry and realizes three functions of searching, downloading, and uploading images. The corresponding Job names of these three functions are “search”, “pull”, and “push” respectively.

  3. Docker Registry can be divided into public repositories (Docker Hub) and private repositories.

Graph “Docker Internal Database”

  1. Graph architecture diagram


2. Repository



  • Custodian of downloaded images (both downloaded images and images built from Dockerfile).

  • A Repository represents a Repository of images of a certain class (e.g., Ubuntu). Images in a Repository are distinguished by tags (representing different tags or versions of images of the same class). A Registry contains multiple repositories, and a Repository contains multiple images of the same type.

  • Image storage types include Aufs, Devicemapper, Btrfs, and Vfs. CentOS versions earlier than 7.x use the Device Apper storage type.

  • The local Graph directory also stores specific information about each container image, including the metadata of the container image, the size information of the container image, and the specific RootFs that the container image represents.

3. GraphDB



  • A logger of the relationships between the downloaded container images.

  • GraphDB is a small database built on SQLite, which implements the naming of nodes and the recording of the association between nodes.

Driver execution part

A Driver is a Driver module in the Docker architecture. Through the Driver, Docker can realize the Docker container execution environment customization. Graph is responsible for storing the image and Driver is responsible for executing the container.

Graphdriver

  1. Graphdriver architecture diagram






2. Graphdriver is mainly used to manage container images, including storage and acquisition.

3. Storage: The image downloaded by Docker pull is stored in the local specified directory (Graph) by Graphdriver.

Docker run (create) uses the image to create the container when the Graphdriver to the local Graph to fetch the image.

Networkdriver

  1. Networkdriver architecture diagram


2. Networkdriver is used to complete the configuration of Docker container network environment, including:

  • Create a bridge for the Docker environment when Docker starts.

  • When a Docker container is created, a dedicated virtual nic device is created for it.

  • Docker containers allocate IP addresses and ports, map ports with hosts, and set container firewall policies.

Execdriver

  1. Execdriver architecture diagram

2. As the execution driver of Docker container, Execdriver is responsible for creating the container running namespace, the statistics and restrictions on the use of container resources, and the real running of the process inside the container, etc.

3. Now Execdriver uses Native drivers by default and does not rely on LXC.

Libcontainer function library

  1. Libcontainer architecture diagram






2. Libcontainer is a Docker library designed and implemented using Go. It is designed to access container-related apis in the kernel without relying on any dependencies.

Docker can directly call Libcontainer to manipulate Namespace, Cgroups, Apparmor, network devices, firewall rules, etc.

4. Libcontainer provides a set of standard interfaces to meet upper-layer requirements for container management. In other words, Libcontainer shields Docker from direct container management.

Docker Container “Final Form of Service Delivery”

  1. Docker Container architecture

2. Docker Container is the ultimate embodiment of service delivery in Docker architecture.

3. Docker customized corresponding Docker containers according to user requirements and instructions:

  • By specifying container images, Docker containers can customize file systems such as Rootfs.

  • By specifying a quota of computing resources, the Docker container uses the specified computing resources.

  • Users can configure the network and its security policies to make the Docker container have an independent and secure network environment.

  • The user makes the Docker container do the specified work by specifying the command to run.


  • Source: Hu Weihuang’s personal blog

  • Original: http://t.cn/RdiV7Sn

  • Photo: From Google Image search

  • Copyright: All rights reserved