?????????????????????????? 第16章：企業(yè)版工具

Docker 企業(yè)版（Enterprise Edition，EE）：企業(yè)需要 Docker 能實(shí)現(xiàn)私有化部署。這通常意味著 Docker 需要一個(gè)本地化部署方案，并且由企業(yè)自己掌控和維護(hù)。這還意味著角色和安全功能需要滿足企業(yè)內(nèi)部的組織結(jié)構(gòu)，并且在安全部門的監(jiān)管之下。同時(shí)還需要一份重要的售后支持協(xié)議。DockerEE 其內(nèi)部包括了上百個(gè)引擎、操作界面以及私有安全注冊。用戶可以本地化部署，并且其中包括了一份支持協(xié)議。上層架構(gòu)如下圖所示。

?

Docker 引擎提供 Docker 全部核心功能。核心功能包括鏡像、容器管理、網(wǎng)絡(luò)、卷、集群、安全等。目前包括兩個(gè)版本：社區(qū)版（CE）和企業(yè)版（EE）。兩個(gè)版本最大的不同是發(fā)布周期和相應(yīng)支持。Docker EE 是按季度發(fā)布，采用基于時(shí)間版本的方案。例如，2018 年 6 月發(fā)布的 Docker EE 叫作 18.06.x-ee。Docker 公司提供持續(xù)一年的支持，并且為每個(gè)版本打補(bǔ)丁。安裝 Docker EE 很簡單。但是，不同平臺(tái)的安裝方式略有不同。Docker EE 是基于訂閱模式的服務(wù)，所以用戶需要一個(gè) Docker ID 并且激活訂閱。然后就可以獲得專享 Docker EE 倉庫。UCP 是企業(yè)級的容器即服務(wù)平臺(tái)的圖形化操作界面。UCP 使用 Docker 引擎，并添加了各種企業(yè)喜歡以及需要的功能。例如 RBAC、可配置、認(rèn)證、高可用控制平面以及簡單界面。在 UCP 內(nèi)部，是一個(gè)容器化的微服務(wù)應(yīng)用，以多個(gè)容器的形式運(yùn)行。

Docker UCP圖形化操作界面：架構(gòu)層面上講，UCP 是基于 Swarm 模式下的 Docker EE 構(gòu)建的。如下圖所示，UCP 控制平面運(yùn)行在 Swarm 管理節(jié)點(diǎn)上，應(yīng)用則部署在 Swarm 工作節(jié)點(diǎn)上。

UCP 管理節(jié)點(diǎn)必須是 Linux。工作節(jié)點(diǎn)既可以 Windows，也可以是 Linux。規(guī)劃 UCP 安裝：在規(guī)劃 UCP 安裝的時(shí)候，合理設(shè)置集群大小和規(guī)格十分重要。下面介紹該過程中需要考慮的一些方面。集群中全部節(jié)點(diǎn)的時(shí)鐘需要同步（例如 NTP）。如果沒有同步，可能導(dǎo)致一些很難定位的問題。全部節(jié)點(diǎn)都要有自己的靜態(tài) IP 地址和固定的 DNS 名稱。默認(rèn)情況下，UCP 管理節(jié)點(diǎn)不運(yùn)行用戶工作負(fù)載。推薦使用這種最佳實(shí)踐，并建議用戶在生產(chǎn)環(huán)境中強(qiáng)制使用。該方式使得管理節(jié)點(diǎn)只需關(guān)注控制平面職責(zé)。同時(shí)也能簡化問題定位。用戶需要保證管理節(jié)點(diǎn)數(shù)量為奇數(shù)。這樣就能避免出現(xiàn)腦裂等類似場景時(shí)，會(huì)導(dǎo)致管理節(jié)點(diǎn)不可用，或者與集群割裂的現(xiàn)象。理想數(shù)量為 3、5 或者 7，3 或者 5 是較常用的。多于 7 的話，可能導(dǎo)致后臺(tái) Raft 算法或者集群一致性的問題。如果不能提供 3 個(gè)管理節(jié)點(diǎn)，1 個(gè)要好于 2 個(gè)！如果配置了后臺(tái)計(jì)劃（用戶應(yīng)當(dāng)配置）并進(jìn)行日常備份，可能需要部署 5 個(gè)管理節(jié)點(diǎn)。這是因?yàn)?Swarm 和 UCP 的備份操作需要停止 Docker 和 UCP 服務(wù)。5 個(gè)管理節(jié)點(diǎn)可以保證在執(zhí)行類似操作時(shí)集群的彈性。管理節(jié)點(diǎn)應(yīng)當(dāng)根據(jù)數(shù)據(jù)中心可用域進(jìn)行部署。用戶最不想見到的場景，就是全部 UCP 管理節(jié)點(diǎn)所在的域都不可用。但是，管理節(jié)點(diǎn)之間的通信必須經(jīng)由高速可靠的網(wǎng)絡(luò)完成。因此如果數(shù)據(jù)中心可用域之間網(wǎng)絡(luò)狀況不佳，最好還是將所有管理節(jié)點(diǎn)部署在相同域之中。有件事已經(jīng)約定成俗，即在公有云上部署時(shí)，需要將管理節(jié)點(diǎn)部署在同區(qū)域內(nèi)的可用域中。跨區(qū)域通常會(huì)受到低可靠性和高延遲網(wǎng)絡(luò)的影響。工作節(jié)點(diǎn)的數(shù)量可以根據(jù)需求設(shè)置，因?yàn)樗鼈儾⒉粫?huì)參與到集群 Raft 操作當(dāng)中，所以就不會(huì)影響控制平面操作。規(guī)劃工作節(jié)點(diǎn)的規(guī)格和數(shù)量，需要理解計(jì)劃部署在集群上的應(yīng)用需求。例如，理解之后能幫助用戶確定需要多少 Windows 節(jié)點(diǎn)和 Linux 節(jié)點(diǎn)。同時(shí)還需要知道應(yīng)用是否有特殊需求，需要工作節(jié)點(diǎn)的定制化來支持，例如 PCI 類工作負(fù)載。
此外，雖然 Docker 引擎是輕量級的，但其上運(yùn)行的容器化應(yīng)用不一定也是。出于這樣的考慮，根據(jù)應(yīng)用的 CPU、RAM、網(wǎng)絡(luò)以及磁盤 I/O 需求規(guī)劃節(jié)點(diǎn)數(shù)目就很重要了。安裝 Docker UCP（略去）

UCP 的訪問控制：所有對 UCP 的訪問，都經(jīng)由身份管理子系統(tǒng)。這意味著用戶在集群上執(zhí)行任何操作前，首先需要通過用戶名和密碼進(jìn)行認(rèn)證。這些操作包括集群的管理，以及服務(wù)的部署和管理。用戶使用 UI 界面的時(shí)候已經(jīng)體驗(yàn)過了，必須使用用戶名和密碼才能登錄。在 CLI 中也是一樣的，用戶不能在未登錄的情況下通過 UCP 執(zhí)行命令！這是因?yàn)?UCP 集群中本地 Docker Socket 受到 ucp-proxy 服務(wù)的保護(hù)，不會(huì)接受未認(rèn)證命令。

UCP 備份：首先并且最重要的是，高可用（HA）并不等價(jià)于備份，思考下面的例子。有一個(gè)包含 5 個(gè)管理節(jié)點(diǎn)的 UCP 集群。所有管理節(jié)點(diǎn)都處于健康狀態(tài)，并且控制平面開啟了復(fù)制功能。某個(gè)心懷怨恨的員工對集群進(jìn)行破壞（或者刪除了全部用戶賬戶）。破壞操作會(huì)復(fù)制到全部 5 個(gè)管理節(jié)點(diǎn)，導(dǎo)致集群被破壞。這種場景下 HA 沒有絲毫幫助。此時(shí)需要的，是備份！一個(gè) UCP 集群主要由 3 個(gè)部分構(gòu)成，也是需要分別備份的內(nèi)容：Swarm、UCP 和 Docker 可信鏡像倉庫服務(wù)（DTR）。恢復(fù) UCP：從備份進(jìn)行恢復(fù)是最后的手段，只能在整個(gè)集群都宕機(jī)或者全部管理節(jié)點(diǎn)都丟失的情況下使用，如果 HA 集群下僅丟失某個(gè)管理節(jié)點(diǎn)，并不需要從備份進(jìn)行恢復(fù)。該情況下，很容易就能創(chuàng)建新管理節(jié)點(diǎn)并加入集群。

Docker可信鏡像倉庫服務(wù)，是安全、高可用并且支持本地部署的 Docker 服務(wù)，通常使用 DTR 代指。如果知道 Docker Hub 是什么，可以將 DTR 理解為私有的 Docker Hub，可以在本地部署，并且自行管理。如果條件允許，使用專用節(jié)點(diǎn)來運(yùn)行 DTR。在 DTR 生產(chǎn)環(huán)境節(jié)點(diǎn)中絕對不要運(yùn)行用戶工作負(fù)載。

????????????????????????????????????? 第17章：企業(yè)及特性

DockerEE 具備這兩個(gè)特性：基于角色的權(quán)限控制（RBAC）和對活動(dòng)目錄（AD）的集成。 1）RBAC：UCP 通過一種稱為授權(quán)（Grant）的東西實(shí)現(xiàn)了 RBAC。大體上，一個(gè)授權(quán)有以下 3 個(gè)概念構(gòu)成。1）主體（Subject）。2）角色（Role）。3）集合（Collection）。主體即一個(gè)或多個(gè)用戶，或一個(gè)團(tuán)隊(duì)。角色是一系列權(quán)限的組合，而集合則是權(quán)限作用的資源，如下圖所示。
?

?

創(chuàng)建一個(gè)授權(quán)包含如下步驟。1）創(chuàng)建用戶和團(tuán)隊(duì)。2）創(chuàng)建一個(gè)自定義的角色。3）創(chuàng)建一個(gè)集合。4）創(chuàng)建一個(gè)授權(quán)。只有 UCP 管理員才可以創(chuàng)建和管理用戶、團(tuán)隊(duì)、角色、集合和授權(quán)。因此讀者需要以UCP管理員的身份登錄才能進(jìn)行更多得操作。節(jié)點(diǎn) RBAC：為了調(diào)度將集群中的工作節(jié)點(diǎn)進(jìn)行分組是可行的。例如，有時(shí)會(huì)為開發(fā)、測試和 QA 負(fù)載運(yùn)行一個(gè)集群——用一個(gè)集群可能會(huì)減少管理開銷，并且可以輕松地將節(jié)點(diǎn)分配給 3 個(gè)不同的環(huán)境。但此時(shí)仍然希望能夠?qū)ぷ鞴?jié)點(diǎn)進(jìn)行區(qū)分，從而實(shí)現(xiàn)諸如僅 dev 團(tuán)隊(duì)的用戶才可以對 dev 集合中的節(jié)點(diǎn)進(jìn)行調(diào)度的效果。這同樣可以基于授權(quán)來實(shí)現(xiàn)。首先，需要將 UCP 工作節(jié)點(diǎn)分配給自定義的集合。然后，基于該集合、內(nèi)置的 Scheduler 角色以及希望為其分配權(quán)限的團(tuán)隊(duì)，來創(chuàng)建授權(quán)。

Docker內(nèi)容信任機(jī)制（DCT）：Docker 鏡像的發(fā)布者可以在將鏡像推送到庫中時(shí)對其進(jìn)行簽名。使用者可以在拉取鏡像時(shí)進(jìn)行校驗(yàn)，或進(jìn)行構(gòu)建或運(yùn)行等操作。長話短說，DCT 確保使用者能夠得到他們想要的鏡像。下圖展示了其總體架構(gòu)。

DCT 實(shí)現(xiàn)的是客戶端的簽名和驗(yàn)證，意味著由 Docker 客戶端執(zhí)行它們。顯然類似這樣的密碼機(jī)制，對于確保在互聯(lián)網(wǎng)上拉取和推送的軟件的可信性是非常重要的，其在整個(gè)技術(shù)棧的各個(gè)層次，以及軟件交付流水線的各個(gè)環(huán)節(jié)都在發(fā)揮越來越重要的作用。在不久的將來，這種加密信任機(jī)制將有望在交付鏈的各個(gè)方面發(fā)揮作用。DCT 可以通過環(huán)境變量 DOCKER_CONTENT_TRUST 來啟用或關(guān)閉。將該環(huán)境變量的值設(shè)置為“1”的話將會(huì)在當(dāng)前會(huì)話開啟 DCT；將其設(shè)置為其他值的話則會(huì)關(guān)閉 DCT。下面的命令用于在 Linux 主機(jī)的 Docker 中開啟 DCT。$ export DOCKER_CONTENT_TRUST，后續(xù)的 docker push 命令會(huì)在推送鏡像時(shí)自動(dòng)對鏡像進(jìn)行簽名。因此，所有的 pull、 build 和 run 命令只會(huì)對已簽名的鏡像起作用。

Docker HTTP路由網(wǎng)格（HRM）：Docker Swarm 內(nèi)置有四層路由網(wǎng)格的功能，稱為 Swarm 路由網(wǎng)格（Swarm Routing Mesh）。這一功能可以使 Swarm 服務(wù)暴露給集群中的所有節(jié)點(diǎn)，并且能夠在服務(wù)的各個(gè)副本之間實(shí)現(xiàn)對入站流量的負(fù)載均衡。其效果就是可以基本實(shí)現(xiàn)流量均衡到達(dá)服務(wù)的所有副本。不過，該負(fù)載均衡并不作用于應(yīng)用層。例如，它無法根據(jù) HTTP 頭部數(shù)據(jù)進(jìn)行七層路由。為了彌補(bǔ)這一點(diǎn)，UCP 實(shí)現(xiàn)了七層路由網(wǎng)格，稱為 HTTP 路由網(wǎng)格（HTTP Routing Mesh，HRM）。這一功能以 Swarm 路由網(wǎng)格為基礎(chǔ)。HRM 使得多個(gè) Swarm 服務(wù)可以發(fā)布在同一個(gè) Swarm 端口上，并根據(jù) HTTP 請求頭中的主機(jī)名將流量路由到正確的服務(wù)中。下圖展示的是包含兩個(gè)服務(wù)的簡單示例。
?

在上圖中，筆記本客戶端向 mustang.internal 的 80 端口發(fā)出了一個(gè) HTTP 請求。UCP 集群中有兩個(gè)監(jiān)聽 80 端口的服務(wù)。mustang 服務(wù)在 80 端口監(jiān)聽發(fā)送給 mustang.internal 主機(jī)的流量。camero 服務(wù)也監(jiān)聽 80 端口，不過它被配置為接收到達(dá) camero.internal 的流量。其實(shí)還有第三個(gè)稱為 HRM 的服務(wù)，用來維護(hù)主機(jī)名與 UCP 服務(wù)之間的映射關(guān)系。HRM 會(huì)接收所有到達(dá) 80 端口的流量，查看 HTTP 請求頭，并決定將其路由到哪個(gè)服務(wù)。

Docker daemon通信與安全客戶端：Docker使用了客戶端—服務(wù)端模型。客戶端使用 CLI，同時(shí)服務(wù)端（daemon）實(shí)現(xiàn)功能，并對外提供 REST API。客戶端叫作 docker（在 Windows 上是 docker.exe），daemon 叫作 dockerd（在 Windows 上是 dockerd.exe）。默認(rèn)安裝方式將客戶端和服務(wù)端安裝在同一臺(tái)主機(jī)上，并且配置通過本地安全 PIC Socket 進(jìn)行通信。不過，也可以配置客戶端和服務(wù)端通過網(wǎng)絡(luò)進(jìn)行通信。但是 daemon 默認(rèn)網(wǎng)絡(luò)配置使用不安全的 HTTP Socket，端口是 2375/tcp，如下圖所示
?

默認(rèn)使用 2375 作為客戶端和服務(wù)端之間未加密通信方式的端口，而 2376 則用于加密通信。在實(shí)驗(yàn)室這樣還可以，但是生產(chǎn)環(huán)境卻是不能接受的。TLS 就是解決之道！Docker 允許用戶配置客戶端和 daemon 間只接收安全的 TLS 方式連接。生產(chǎn)環(huán)境中推薦這種配置，即使在可信內(nèi)部網(wǎng)絡(luò)中，也建議如此配置！Docker 為客戶端與 daemon 間使用基于 TLS 的安全通信提供了兩種模式。1）daemon 模式：Docker daemon 只接收認(rèn)證客戶端的鏈接。2）客戶端模式：Docker 客戶端只接收擁有證書的 Docker daemon 發(fā)起的鏈接，其中證書需要由可信 CA 簽發(fā)。同時(shí)使用兩種模式能提供最高的安全等級。Docker 支持兩種 TLS 模式。daemon模式、客戶端模式。daemon 模式保證 daemon 只處理來自擁有有效證書的客戶端發(fā)起的連接，客戶端模式使得客戶端只能連接到擁有有效證書的 daemon。

?

Docker整體架構(gòu)：

distribution 負(fù)責(zé)與docker registry交互，上傳鏡像以及v2 registry 有關(guān)的源數(shù)據(jù)。registry負(fù)責(zé)docker registry有關(guān)的身份認(rèn)證、鏡像查找、鏡像驗(yàn)證以及管理registry mirror等交互操作。image 負(fù)責(zé)與鏡像源數(shù)據(jù)有關(guān)的存儲(chǔ)、查找，鏡像層的索引、查找以及鏡像tar包有關(guān)的導(dǎo)入、導(dǎo)出操作。reference負(fù)責(zé)存儲(chǔ)本地所有鏡像的repository和tag名，并維護(hù)與鏡像id之間的映射關(guān)系。layer模塊負(fù)責(zé)與鏡像層和容器層源數(shù)據(jù)有關(guān)的增刪改查，并負(fù)責(zé)將鏡像層的增刪改查映射到實(shí)際存儲(chǔ)鏡像層文件的graphdriver模塊。graghdriver是所有與容器鏡像相關(guān)操作的執(zhí)行者。

架構(gòu)2

用戶使用Docker Client與Docker Daemon建立通信，并發(fā)送請求給后者。而Docker Daemon作為Docker架構(gòu)中的主體部分，首先提供Server的功能使其可以接受Docker Client的請求；而后Engine執(zhí)行Docker內(nèi)部的一系列工作，每一項(xiàng)工作都是以一個(gè)Job的形式的存在。Job的運(yùn)行過程中，當(dāng)需要容器鏡像時(shí)，則從Docker Registry中下載鏡像，并通過鏡像管理驅(qū)動(dòng)graphdriver將下載鏡像以Graph的形式存儲(chǔ)；當(dāng)需要為Docker創(chuàng)建網(wǎng)絡(luò)環(huán)境時(shí)，通過網(wǎng)絡(luò)管理驅(qū)動(dòng)networkdriver創(chuàng)建并配置Docker容器網(wǎng)絡(luò)環(huán)境；當(dāng)需要限制Docker容器運(yùn)行資源或執(zhí)行用戶指令等操作時(shí)，則通過execdriver來完成。而libcontainer是一項(xiàng)獨(dú)立的容器管理包，networkdriver以及execdriver都是通過libcontainer來實(shí)現(xiàn)具體對容器進(jìn)行的操作。當(dāng)執(zhí)行完運(yùn)行容器的命令后，一個(gè)實(shí)際的Docker容器就處于運(yùn)行狀態(tài)，該容器擁有獨(dú)立的文件系統(tǒng)，獨(dú)立并且安全的運(yùn)行環(huán)境等。

架構(gòu)3

?

?

這個(gè)個(gè)架構(gòu)就簡單清晰指明了server/client交互，容器和鏡像、數(shù)據(jù)之間的一些聯(lián)系。docker daemon就是docker的守護(hù)進(jìn)程即server端，可以是遠(yuǎn)程的，也可以是本地的，這個(gè)不是C/S架構(gòu)嗎，客戶端Docker client 是通過rest api進(jìn)行通信。docker cli 用來管理容器和鏡像，客戶端提供一個(gè)只讀鏡像，然后通過鏡像可以創(chuàng)建多個(gè)容器，這些容器可以只是一個(gè)RFS（Root file system根文件系統(tǒng)），也可以ishi一個(gè)包含了用戶應(yīng)用的RFS，容器再docker client中只是要給進(jìn)程，兩個(gè)進(jìn)程之間互不可見。用戶不能與server直接交互，但可以通過與容器這個(gè)橋梁來交互，由于是操作系統(tǒng)級別的虛擬技術(shù)，中間的損耗幾乎可以不計(jì)。

總結(jié)

以上是生活随笔為你收集整理的深入浅出Docker 读书笔记（九）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。