[[279395]]

前言

Docker 簡(jiǎn)介

Docker 是 Docker 公司開(kāi)源的一個(gè)基于輕量級(jí)虛擬化技術(shù)的容器引擎項(xiàng)目, 整個(gè)項(xiàng)目基于 Go 語(yǔ)言開(kāi)發(fā)，并遵從 Apache 2.0 協(xié)議。目前，Docker 可以在容器內(nèi)部快速自動(dòng)化部署應(yīng)用，并可以通過(guò)內(nèi)核虛擬化技術(shù)(namespaces 及 cgroups 等)來(lái)提供容器的資源隔離與安全保障等。由于 Docker 通過(guò)操作系統(tǒng)層的虛擬化實(shí)現(xiàn)隔離，所以 Docker 容器在運(yùn)行時(shí)，不需要類似虛擬機(jī)(VM)額外的操作系統(tǒng)開(kāi)銷，提高資源利用率，并且提升諸如 IO 等方面的性能。

由于眾多新穎的特性以及項(xiàng)目本身的開(kāi)放性，Docker 在不到兩年的時(shí)間里迅速獲得諸多廠商的青睞，其中更是包括 Google、Microsoft、VMware 等業(yè)界行業(yè)領(lǐng)導(dǎo)者。 Google 在今年六月份推出了 Kubernetes ，提供 Docker 容器的調(diào)度服務(wù)，而今年 8 月 Microsoft 宣布 Azure 上支持 Kubernetes ，隨后傳統(tǒng)虛擬化巨頭VMware 宣布與Docker 強(qiáng)強(qiáng)合作。今年9 月中旬， Docker 更是獲得 4000 萬(wàn)美元的 C 輪融資，以推動(dòng)分布式應(yīng)用方面的發(fā)展。

從目前的形勢(shì)來(lái)看，Docker 的前景一片大好。本系列文章從源碼的角度出發(fā)，詳細(xì)介紹 Docker 的架構(gòu)、Docker 的運(yùn)行以及 Docker 的卓越特性。本文是 Docker 源碼分析系列的第一篇­­­——Docker 架構(gòu)篇。

Docker 版本

本文關(guān)于 Docker 架構(gòu)的分析都是基于 Docker 的源碼與 Docker 相應(yīng)版本的運(yùn)行結(jié)果，其中 Docker 為最新的 1.2 版本。

Docker 架構(gòu)分析內(nèi)容目錄

本文的目的是：在理解 Docker 源代碼的基礎(chǔ)上，分析 Docker 架構(gòu)。分析過(guò)程中主要按照以下三個(gè)步驟進(jìn)行：

• Docker 的總架構(gòu)圖展示
• Docker 架構(gòu)圖內(nèi)部各模塊功能與實(shí)現(xiàn)分析
• 以 Docker 命令的執(zhí)行為例，進(jìn)行 Docker 運(yùn)行流程闡述

Docker 總架構(gòu)圖

學(xué)習(xí) Docker 的源碼并不是一個(gè)枯燥的過(guò)程，反而可以從中理解 Docker 架構(gòu)的設(shè)計(jì)原理。Docker 對(duì)使用者來(lái)講是一個(gè) C/S 模式的架構(gòu)，而 Docker 的后端是一個(gè)非常松耦合的架構(gòu)，模塊各司其職，并有機(jī)組合，支撐 Docker 的運(yùn)行。

在此，先附上 Docker 總架構(gòu)，如圖 

Docker 總架構(gòu)圖

不難看出，用戶是使用 Docker Client 與 Docker Daemon 建立通信，并發(fā)送請(qǐng)求給后者。

而 Docker Daemon 作為 Docker 架構(gòu)中的主體部分，首先提供 Server 的功能使其可以接受 Docker Client 的請(qǐng)求;而后 Engine 執(zhí)行 Docker 內(nèi)部的一系列工作，每一項(xiàng)工作都是以一個(gè) Job 的形式的存在。

Job 的運(yùn)行過(guò)程中，當(dāng)需要容器鏡像時(shí)，則從 Docker Registry 中下載鏡像，并通過(guò)鏡像管理驅(qū)動(dòng) graphdriver 將下載鏡像以 Graph 的形式存儲(chǔ);當(dāng)需要為 Docker 創(chuàng)建網(wǎng)絡(luò)環(huán)境時(shí)，通過(guò)網(wǎng)絡(luò)管理驅(qū)動(dòng) networkdriver 創(chuàng)建并配置 Docker 容器網(wǎng)絡(luò)環(huán)境;當(dāng)需要限制 Docker 容器運(yùn)行資源或執(zhí)行用戶指令等操作時(shí)，則通過(guò) execdriver 來(lái)完成。

而 libcontainer 是一項(xiàng)獨(dú)立的容器管理包，networkdriver 以及 execdriver 都是通過(guò) libcontainer 來(lái)實(shí)現(xiàn)具體對(duì)容器進(jìn)行的操作。

當(dāng)執(zhí)行完運(yùn)行容器的命令后，一個(gè)實(shí)際的 Docker 容器就處于運(yùn)行狀態(tài)，該容器擁有獨(dú)立的文件系統(tǒng)，獨(dú)立并且安全的運(yùn)行環(huán)境等。

Docker 架構(gòu)內(nèi)各模塊的功能與實(shí)現(xiàn)分析

接下來(lái)，我們將從 Docker 總架構(gòu)圖入手，抽離出架構(gòu)內(nèi)各個(gè)模塊，并對(duì)各個(gè)模塊進(jìn)行更為細(xì)化的架構(gòu)分析與功能闡述。主要的模塊有：Docker Client、Docker Daemon、Docker Registry、Graph、Driver、libcontainer 以及 Docker container。

Docker Client

Docker Client 是 Docker 架構(gòu)中用戶用來(lái)和 Docker Daemon 建立通信的客戶端。用戶使用的可執(zhí)行文件為 docker，通過(guò) docker 命令行工具可以發(fā)起眾多管理 container 的請(qǐng)求。

Docker Client 可以通過(guò)以下三種方式和 Docker Daemon 建立通信：tcp://host:port，unix://path_to_socket 和 fd://socketfd。為了簡(jiǎn)單起見(jiàn)，本文一律使用第一種方式作為講述兩者通信的原型。與此同時(shí)，與 Docker Daemon 建立連接并傳輸請(qǐng)求的時(shí)候，Docker Client 可以通過(guò)設(shè)置命令行 flag 參數(shù)的形式設(shè)置安全傳輸層協(xié)議 (TLS) 的有關(guān)參數(shù)，保證傳輸?shù)陌踩浴?/p>

Docker Client 發(fā)送容器管理請(qǐng)求后，由 Docker Daemon 接受并處理請(qǐng)求，當(dāng) Docker Client 接收到返回的請(qǐng)求相應(yīng)并簡(jiǎn)單處理后，Docker Client 一次完整的生命周期就結(jié)束了。當(dāng)需要繼續(xù)發(fā)送容器管理請(qǐng)求時(shí)，用戶必須再次通過(guò) docker 可執(zhí)行文件創(chuàng)建 Docker Client。

Docker Daemon

Docker Daemon 是 Docker 架構(gòu)中一個(gè)常駐在后臺(tái)的系統(tǒng)進(jìn)程，功能是：接受并處理 Docker Client 發(fā)送的請(qǐng)求。該守護(hù)進(jìn)程在后臺(tái)啟動(dòng)了一個(gè) Server，Server 負(fù)責(zé)接受 Docker Client 發(fā)送的請(qǐng)求;接受請(qǐng)求后，Server 通過(guò)路由與分發(fā)調(diào)度，找到相應(yīng)的 Handler 來(lái)執(zhí)行請(qǐng)求。

Docker Daemon 啟動(dòng)所使用的可執(zhí)行文件也為 docker，與 Docker Client 啟動(dòng)所使用的可執(zhí)行文件 docker 相同。在 docker 命令執(zhí)行時(shí)，通過(guò)傳入的參數(shù)來(lái)判別 Docker Daemon 與 Docker Client。

Docker Daemon 的架構(gòu)，大致可以分為以下三部分：Docker Server、Engine 和 Job。Daemon 架構(gòu)。 

圖Docker Daemon 架構(gòu)示意圖

Docker Server 在 Docker 架構(gòu)中是專門服務(wù)于 Docker Client 的 server。該 server 的功能是：接受并調(diào)度分發(fā) Docker Client 發(fā)送的請(qǐng)求。Docker Server 的架構(gòu)如圖 4.2。 

圖 4.2 Docker Server 架構(gòu)示意圖

在 Docker 的啟動(dòng)過(guò)程中，通過(guò)包 gorilla/mux，創(chuàng)建了一個(gè) mux.Router，提供請(qǐng)求的路由功能。在 Golang 中，gorilla/mux 是一個(gè)強(qiáng)大的 URL 路由器以及調(diào)度分發(fā)器。該 mux.Router 中添加了眾多的路由項(xiàng)，每一個(gè)路由項(xiàng)由 HTTP 請(qǐng)求方法(PUT、POST、GET 或 DELETE)、URL、Handler 三部分組成。

若 Docker Client 通過(guò) HTTP 的形式訪問(wèn) Docker Daemon，創(chuàng)建完 mux.Router 之后，Docker 將 Server 的監(jiān)聽(tīng)地址以及 mux.Router 作為參數(shù)，創(chuàng)建一個(gè) httpSrv=http.Server{}，最終執(zhí)行 httpSrv.Serve() 為請(qǐng)求服務(wù)。

在 Server 的服務(wù)過(guò)程中，Server 在 listener 上接受 Docker Client 的訪問(wèn)請(qǐng)求，并創(chuàng)建一個(gè)全新的 goroutine 來(lái)服務(wù)該請(qǐng)求。在 goroutine 中，首先讀取請(qǐng)求內(nèi)容，然后做解析工作，接著找到相應(yīng)的路由項(xiàng)，隨后調(diào)用相應(yīng)的 Handler 來(lái)處理該請(qǐng)求，最后 Handler 處理完請(qǐng)求之后回復(fù)該請(qǐng)求。

需要注意的是：Docker Server 的運(yùn)行在 Docker 的啟動(dòng)過(guò)程中，是靠一個(gè)名為"serveapi"的 job 的運(yùn)行來(lái)完成的。原則上，Docker Server 的運(yùn)行是眾多 job 中的一個(gè)，但是為了強(qiáng)調(diào) Docker Server 的重要性以及為后續(xù) job 服務(wù)的重要特性，將該"serveapi"的 job 單獨(dú)抽離出來(lái)分析，理解為 Docker Server。

4.2.2 Engine

Engine 是 Docker 架構(gòu)中的運(yùn)行引擎，同時(shí)也 Docker 運(yùn)行的核心模塊。它扮演 Docker container 存儲(chǔ)倉(cāng)庫(kù)的角色，并且通過(guò)執(zhí)行 job 的方式來(lái)操縱管理這些容器。

在 Engine 數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)與實(shí)現(xiàn)過(guò)程中，有一個(gè) handler 對(duì)象。該 handler 對(duì)象存儲(chǔ)的都是關(guān)于眾多特定 job 的 handler 處理訪問(wèn)。舉例說(shuō)明，Engine 的 handler 對(duì)象中有一項(xiàng)為：{"create": daemon.ContainerCreate,}，則說(shuō)明當(dāng)名為"create"的 job 在運(yùn)行時(shí)，執(zhí)行的是 daemon.ContainerCreate 的 handler。

4.2.3 Job

一個(gè) Job 可以認(rèn)為是 Docker 架構(gòu)中 Engine 內(nèi)部最基本的工作執(zhí)行單元。Docker 可以做的每一項(xiàng)工作，都可以抽象為一個(gè) job。例如：在容器內(nèi)部運(yùn)行一個(gè)進(jìn)程，這是一個(gè) job;創(chuàng)建一個(gè)新的容器，這是一個(gè) job，從 Internet 上下載一個(gè)文檔，這是一個(gè) job;包括之前在 Docker Server 部分說(shuō)過(guò)的，創(chuàng)建 Server 服務(wù)于 HTTP 的 API，這也是一個(gè) job，等等。

Job 的設(shè)計(jì)者，把 Job 設(shè)計(jì)得與 Unix 進(jìn)程相仿。比如說(shuō)：Job 有一個(gè)名稱，有參數(shù)，有環(huán)境變量，有標(biāo)準(zhǔn)的輸入輸出，有錯(cuò)誤處理，有返回狀態(tài)等。

4.3 Docker Registry

Docker Registry 是一個(gè)存儲(chǔ)容器鏡像的倉(cāng)庫(kù)。而容器鏡像是在容器被創(chuàng)建時(shí)，被加載用來(lái)初始化容器的文件架構(gòu)與目錄。

在 Docker 的運(yùn)行過(guò)程中，Docker Daemon 會(huì)與 Docker Registry 通信，并實(shí)現(xiàn)搜索鏡像、下載鏡像、上傳鏡像三個(gè)功能，這三個(gè)功能對(duì)應(yīng)的 job 名稱分別為"search"，"pull" 與 "push"。

其中，在 Docker 架構(gòu)中，Docker 可以使用公有的 Docker Registry，即大家熟知的 Docker Hub ，如此一來(lái)，Docker 獲取容器鏡像文件時(shí)，必須通過(guò)互聯(lián)網(wǎng)訪問(wèn) Docker Hub;同時(shí) Docker 也允許用戶構(gòu)建本地私有的 Docker Registry，這樣可以保證容器鏡像的獲取在內(nèi)網(wǎng)完成。

4.4 Graph

Graph 在 Docker 架構(gòu)中扮演已下載容器鏡像的保管者，以及已下載容器鏡像之間關(guān)系的記錄者。一方面，Graph 存儲(chǔ)著本地具有版本信息的文件系統(tǒng)鏡像，另一方面也通過(guò) GraphDB 記錄著所有文件系統(tǒng)鏡像彼此之間的關(guān)系。Graph 的架構(gòu)如圖 4.3。 

圖 4.3 Graph 架構(gòu)示意圖

其中，GraphDB 是一個(gè)構(gòu)建在 SQLite 之上的小型圖數(shù)據(jù)庫(kù)，實(shí)現(xiàn)了節(jié)點(diǎn)的命名以及節(jié)點(diǎn)之間關(guān)聯(lián)關(guān)系的記錄。它僅僅實(shí)現(xiàn)了大多數(shù)圖數(shù)據(jù)庫(kù)所擁有的一個(gè)小的子集，但是提供了簡(jiǎn)單的接口表示節(jié)點(diǎn)之間的關(guān)系。

同時(shí)在 Graph 的本地目錄中，關(guān)于每一個(gè)的容器鏡像，具體存儲(chǔ)的信息有：該容器鏡像的元數(shù)據(jù)，容器鏡像的大小信息，以及該容器鏡像所代表的具體 rootfs。

4.5 Driver

Driver 是 Docker 架構(gòu)中的驅(qū)動(dòng)模塊。通過(guò) Driver 驅(qū)動(dòng)，Docker 可以實(shí)現(xiàn)對(duì) Docker 容器執(zhí)行環(huán)境的定制。由于 Docker 運(yùn)行的生命周期中，并非用戶所有的操作都是針對(duì) Docker 容器的管理，另外還有關(guān)于 Docker 運(yùn)行信息的獲取，Graph 的存儲(chǔ)與記錄等。因此，為了將 Docker 容器的管理從 Docker Daemon 內(nèi)部業(yè)務(wù)邏輯中區(qū)分開(kāi)來(lái)，設(shè)計(jì)了 Driver 層驅(qū)動(dòng)來(lái)接管所有這部分請(qǐng)求。

在 Docker Driver 的實(shí)現(xiàn)中，可以分為以下三類驅(qū)動(dòng)：graphdriver、networkdriver 和 execdriver。

graphdriver 主要用于完成容器鏡像的管理，包括存儲(chǔ)與獲取。即當(dāng)用戶需要下載指定的容器鏡像時(shí)，graphdriver 將容器鏡像存儲(chǔ)在本地的指定目錄;同時(shí)當(dāng)用戶需要使用指定的容器鏡像來(lái)創(chuàng)建容器的 rootfs 時(shí)，graphdriver 從本地鏡像存儲(chǔ)目錄中獲取指定的容器鏡像。

在 graphdriver 的初始化過(guò)程之前，有 4 種文件系統(tǒng)或類文件系統(tǒng)在其內(nèi)部注冊(cè)，它們分別是 aufs、btrfs、vfs 和 devmapper。而 Docker 在初始化之時(shí)，通過(guò)獲取系統(tǒng)環(huán)境變量”DOCKER_DRIVER”來(lái)提取所使用 driver 的指定類型。而之后所有的 graph 操作，都使用該 driver 來(lái)執(zhí)行。

graphdriver 的架構(gòu)如圖 4.4： 

圖 4.4 graphdriver 架構(gòu)示意圖

networkdriver 的用途是完成 Docker 容器網(wǎng)絡(luò)環(huán)境的配置，其中包括 Docker 啟動(dòng)時(shí)為 Docker 環(huán)境創(chuàng)建網(wǎng)橋;Docker 容器創(chuàng)建時(shí)為其創(chuàng)建專屬虛擬網(wǎng)卡設(shè)備;以及為 Docker 容器分配 IP、端口并與宿主機(jī)做端口映射，設(shè)置容器防火墻策略等。networkdriver 的架構(gòu)如圖 4.5： 

圖 4. 5 networkdriver 架構(gòu)示意圖

execdriver 作為 Docker 容器的執(zhí)行驅(qū)動(dòng)，負(fù)責(zé)創(chuàng)建容器運(yùn)行命名空間，負(fù)責(zé)容器資源使用的統(tǒng)計(jì)與限制，負(fù)責(zé)容器內(nèi)部進(jìn)程的真正運(yùn)行等。在 execdriver 的實(shí)現(xiàn)過(guò)程中，原先可以使用 LXC 驅(qū)動(dòng)調(diào)用 LXC 的接口，來(lái)操縱容器的配置以及生命周期，而現(xiàn)在 execdriver 默認(rèn)使用 native 驅(qū)動(dòng)，不依賴于 LXC。具體體現(xiàn)在 Daemon 啟動(dòng)過(guò)程中加載的 ExecDriverflag 參數(shù)，該參數(shù)在配置文件已經(jīng)被設(shè)為"native"。這可以認(rèn)為是 Docker 在 1.2 版本上一個(gè)很大的改變，或者說(shuō) Docker 實(shí)現(xiàn)跨平臺(tái)的一個(gè)先兆。execdriver 架構(gòu)如圖 4.6： 

圖 4.6 execdriver 架構(gòu)示意圖

4.6 libcontainer

libcontainer 是 Docker 架構(gòu)中一個(gè)使用 Go 語(yǔ)言設(shè)計(jì)實(shí)現(xiàn)的庫(kù)，設(shè)計(jì)初衷是希望該庫(kù)可以不依靠任何依賴，直接訪問(wèn)內(nèi)核中與容器相關(guān)的 API。

正是由于 libcontainer 的存在，Docker 可以直接調(diào)用 libcontainer，而最終操縱容器的 namespace、cgroups、apparmor、網(wǎng)絡(luò)設(shè)備以及防火墻規(guī)則等。這一系列操作的完成都不需要依賴 LXC 或者其他包。libcontainer 架構(gòu)如圖 4.7： 

libcontainer 示意圖

另外，libcontainer 提供了一整套標(biāo)準(zhǔn)的接口來(lái)滿足上層對(duì)容器管理的需求?；蛘哒f(shuō)，libcontainer 屏蔽了 Docker 上層對(duì)容器的直接管理。又由于 libcontainer 使用 Go 這種跨平臺(tái)的語(yǔ)言開(kāi)發(fā)實(shí)現(xiàn)，且本身又可以被上層多種不同的編程語(yǔ)言訪問(wèn)，因此很難說(shuō)，未來(lái)的 Docker 就一定會(huì)緊緊地和 Linux 捆綁在一起。而于此同時(shí)，Microsoft 在其著名云計(jì)算平臺(tái) Azure 中，也添加了對(duì) Docker 的支持，可見(jiàn) Docker 的開(kāi)放程度與業(yè)界的火熱度。

暫不談 Docker，由于 libcontainer 的功能以及其本身與系統(tǒng)的松耦合特性，很有可能會(huì)在其他以容器為原型的平臺(tái)出現(xiàn)，同時(shí)也很有可能催生出云計(jì)算領(lǐng)域全新的項(xiàng)目。

4.7 Docker container

Docker container(Docker 容器)是 Docker 架構(gòu)中服務(wù)交付的最終體現(xiàn)形式。

Docker 按照用戶的需求與指令，訂制相應(yīng)的 Docker 容器：

用戶通過(guò)指定容器鏡像，使得 Docker 容器可以自定義 rootfs 等文件系統(tǒng);

用戶通過(guò)指定計(jì)算資源的配額，使得 Docker 容器使用指定的計(jì)算資源;

用戶通過(guò)配置網(wǎng)絡(luò)及其安全策略，使得 Docker 容器擁有獨(dú)立且安全的網(wǎng)絡(luò)環(huán)境;

用戶通過(guò)指定運(yùn)行的命令，使得 Docker 容器執(zhí)行指定的工作。

Docker 容器示意圖如圖 4.8： 

圖 4.8 Docker 容器示意圖

5 Docker 運(yùn)行案例分析

上一章節(jié)著重于 Docker 架構(gòu)中各個(gè)部分的介紹。本章的內(nèi)容，將以串聯(lián) Docker 各模塊來(lái)簡(jiǎn)要分析，分析原型為 Docker 中的 docker pull 與 docker run 兩個(gè)命令。

5.1 docker pull

docker pull 命令的作用為：從 Docker Registry 中下載指定的容器鏡像，并存儲(chǔ)在本地的 Graph 中，以備后續(xù)創(chuàng)建 Docker 容器時(shí)的使用。docker pull 命令執(zhí)行流程如圖 5.1。 

圖 5.1 docker pull 命令執(zhí)行流程示意圖

如圖，圖中標(biāo)記的紅色箭頭表示 docker pull 命令在發(fā)起后，Docker 所做的一系列運(yùn)行。以下逐一分析這些步驟。

(1) Docker Client 接受 docker pull 命令，解析完請(qǐng)求以及收集完請(qǐng)求參數(shù)之后，發(fā)送一個(gè) HTTP 請(qǐng)求給 Docker Server，HTTP 請(qǐng)求方法為 POST，請(qǐng)求 URL 為"/images/create? "+"xxx";

(2) Docker Server 接受以上 HTTP 請(qǐng)求，并交給 mux.Router，mux.Router 通過(guò) URL 以及請(qǐng)求方法來(lái)確定執(zhí)行該請(qǐng)求的具體 handler;

(3) mux.Router 將請(qǐng)求路由分發(fā)至相應(yīng)的 handler，具體為 PostImagesCreate;

(4) 在 PostImageCreate 這個(gè) handler 之中，一個(gè)名為"pull"的 job 被創(chuàng)建，并開(kāi)始執(zhí)行;

(5) 名為"pull"的 job 在執(zhí)行過(guò)程中，執(zhí)行 pullRepository 操作，即從 Docker Registry 中下載相應(yīng)的一個(gè)或者多個(gè) image;

(6) 名為"pull"的 job 將下載的 image 交給 graphdriver;

(7) graphdriver 負(fù)責(zé)將 image 進(jìn)行存儲(chǔ)，一方創(chuàng)建 graph 對(duì)象，另一方面在 GraphDB 中記錄 image 之間的關(guān)系。

5.2 docker run

docker run 命令的作用是在一個(gè)全新的 Docker 容器內(nèi)部運(yùn)行一條指令。Docker 在執(zhí)行這條命令的時(shí)候，所做工作可以分為兩部分：第一，創(chuàng)建 Docker 容器所需的 rootfs;第二，創(chuàng)建容器的網(wǎng)絡(luò)等運(yùn)行環(huán)境，并真正運(yùn)行用戶指令。因此，在整個(gè)執(zhí)行流程中，Docker Client 給 Docker Server 發(fā)送了兩次 HTTP 請(qǐng)求，第二次請(qǐng)求的發(fā)起取決于第一次請(qǐng)求的返回狀態(tài)。Docker run 命令執(zhí)行流程如圖 5.2。 

圖 5.2 docker run 命令執(zhí)行流程示意圖

如圖，圖中標(biāo)記的紅色箭頭表示 docker run 命令在發(fā)起后，Docker 所做的一系列運(yùn)行。以下逐一分析這些步驟。

(1) Docker Client 接受 docker run 命令，解析完請(qǐng)求以及收集完請(qǐng)求參數(shù)之后，發(fā)送一個(gè) HTTP 請(qǐng)求給 Docker Server，HTTP 請(qǐng)求方法為 POST，請(qǐng)求 URL 為"/containers/create? "+"xxx";

(2) Docker Server 接受以上 HTTP 請(qǐng)求，并交給 mux.Router，mux.Router 通過(guò) URL 以及請(qǐng)求方法來(lái)確定執(zhí)行該請(qǐng)求的具體 handler;

(3) mux.Router 將請(qǐng)求路由分發(fā)至相應(yīng)的 handler，具體為 PostContainersCreate;

(4) 在 PostImageCreate 這個(gè) handler 之中，一個(gè)名為"create"的 job 被創(chuàng)建，并開(kāi)始讓該 job 運(yùn)行;

(5) 名為"create"的 job 在運(yùn)行過(guò)程中，執(zhí)行 Container.Create 操作，該操作需要獲取容器鏡像來(lái)為 Docker 容器創(chuàng)建 rootfs，即調(diào)用 graphdriver;

(6) graphdriver 從 Graph 中獲取創(chuàng)建 Docker 容器 rootfs 所需要的所有的鏡像;

(7) graphdriver 將 rootfs 所有鏡像，加載安裝至 Docker 容器指定的文件目錄下;

(8) 若以上操作全部正常執(zhí)行，沒(méi)有返回錯(cuò)誤或異常，則 Docker Client 收到 Docker Server 返回狀態(tài)之后，發(fā)起第二次 HTTP 請(qǐng)求。請(qǐng)求方法為"POST"，請(qǐng)求 URL 為"/containers/"+container_ID+"/start";

(9) Docker Server 接受以上 HTTP 請(qǐng)求，并交給 mux.Router，mux.Router 通過(guò) URL 以及請(qǐng)求方法來(lái)確定執(zhí)行該請(qǐng)求的具體 handler;

(10)mux.Router 將請(qǐng)求路由分發(fā)至相應(yīng)的 handler，具體為 PostContainersStart;

(11) 在 PostContainersStart 這個(gè) handler 之中，名為"start"的 job 被創(chuàng)建，并開(kāi)始執(zhí)行;

(12) 名為"start"的 job 執(zhí)行完初步的配置工作后，開(kāi)始配置與創(chuàng)建網(wǎng)絡(luò)環(huán)境，調(diào)用 networkdriver;

(13)networkdriver 需要為指定的 Docker 容器創(chuàng)建網(wǎng)絡(luò)接口設(shè)備，并為其分配 IP，port，以及設(shè)置防火墻規(guī)則，相應(yīng)的操作轉(zhuǎn)交至 libcontainer 中的 netlink 包來(lái)完成;

(14)netlink 完成 Docker 容器的網(wǎng)絡(luò)環(huán)境配置與創(chuàng)建;

(15) 返回至名為"start"的 job，執(zhí)行完一些輔助性操作后，job 開(kāi)始執(zhí)行用戶指令，調(diào)用 execdriver;

(16)execdriver 被調(diào)用，初始化 Docker 容器內(nèi)部的運(yùn)行環(huán)境，如命名空間，資源控制與隔離，以及用戶命令的執(zhí)行，相應(yīng)的操作轉(zhuǎn)交至 libcontainer 來(lái)完成;

(17)libcontainer 被調(diào)用，完成 Docker 容器內(nèi)部的運(yùn)行環(huán)境初始化，并最終執(zhí)行用戶要求啟動(dòng)的命令。