第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直接交互，但可以通過與容器這個橋樑來交互，由於是操作系統級別的虛擬技術，中間的損耗幾乎可以不計。