?????????????????????????? 第16章：企業版工具

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

?

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

Docker UCP圖形化操作界面：架構層面上講，UCP 是基于 Swarm 模式下的 Docker EE 構建的。如下圖所示，UCP 控制平面運行在 Swarm 管理節點上，應用則部署在 Swarm 工作節點上。

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

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

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

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

????????????????????????????????????? 第17章：企業及特性

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

?

創建一個授權包含如下步驟。1）創建用戶和團隊。2）創建一個自定義的角色。3）創建一個集合。4）創建一個授權。只有 UCP 管理員才可以創建和管理用戶、團隊、角色、集合和授權。因此讀者需要以UCP管理員的身份登錄才能進行更多得操作。節點 RBAC：為了調度將集群中的工作節點進行分組是可行的。例如，有時會為開發、測試和 QA 負載運行一個集群——用一個集群可能會減少管理開銷，并且可以輕松地將節點分配給 3 個不同的環境。但此時仍然希望能夠對工作節點進行區分，從而實現諸如僅 dev 團隊的用戶才可以對 dev 集合中的節點進行調度的效果。這同樣可以基于授權來實現。首先，需要將 UCP 工作節點分配給自定義的集合。然后，基于該集合、內置的 Scheduler 角色以及希望為其分配權限的團隊，來創建授權。

Docker內容信任機制（DCT）：Docker 鏡像的發布者可以在將鏡像推送到庫中時對其進行簽名。使用者可以在拉取鏡像時進行校驗，或進行構建或運行等操作。長話短說，DCT 確保使用者能夠得到他們想要的鏡像。下圖展示了其總體架構。

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

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

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

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

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

?

Docker整體架構：

distribution 負責與docker registry交互，上傳鏡像以及v2 registry 有關的源數據。registry負責docker registry有關的身份認證、鏡像查找、鏡像驗證以及管理registry mirror等交互操作。image 負責與鏡像源數據有關的存儲、查找，鏡像層的索引、查找以及鏡像tar包有關的導入、導出操作。reference負責存儲本地所有鏡像的repository和tag名，并維護與鏡像id之間的映射關系。layer模塊負責與鏡像層和容器層源數據有關的增刪改查，并負責將鏡像層的增刪改查映射到實際存儲鏡像層文件的graphdriver模塊。graghdriver是所有與容器鏡像相關操作的執行者。

架構2

用戶使用Docker Client與Docker Daemon建立通信，并發送請求給后者。而Docker Daemon作為Docker架構中的主體部分，首先提供Server的功能使其可以接受Docker Client的請求；而后Engine執行Docker內部的一系列工作，每一項工作都是以一個Job的形式的存在。Job的運行過程中，當需要容器鏡像時，則從Docker Registry中下載鏡像，并通過鏡像管理驅動graphdriver將下載鏡像以Graph的形式存儲；當需要為Docker創建網絡環境時，通過網絡管理驅動networkdriver創建并配置Docker容器網絡環境；當需要限制Docker容器運行資源或執行用戶指令等操作時，則通過execdriver來完成。而libcontainer是一項獨立的容器管理包，networkdriver以及execdriver都是通過libcontainer來實現具體對容器進行的操作。當執行完運行容器的命令后，一個實際的Docker容器就處于運行狀態，該容器擁有獨立的文件系統，獨立并且安全的運行環境等。

架構3

?

?

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。