Docker UCP

UCP 是企業級的容器即服務平臺的圖形化操作界面。UCP 使用 Docker 引擎，并添加了各種企業喜歡以及需要的功能。例如 RBAC、可配置、認證、高可用控制平面以及簡單界面。在 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 網站上對 Linux Docker UCP 2.2.4 的最低配置有如下建議。

? UCP 管理節點運行 DTR：8GB RAM，3GB 磁盤空間。

? UCP 工作節點：4GB RAM，3GB 空閑磁盤空間。

推薦配置如下。

? 運行 DTR 的 UCP 管理節點：8GB RAM，4 核 CPU，100GB 磁盤。

? UCP 工作節點：4GB RAM，25-100GB 空閑磁盤空間。

該建議僅供參考，用戶在確定配置時需要自己多加練習。

有一點是確認的：Window 鏡像會比 Linux 鏡像稍大一些。所以規劃時務必考慮該因素。

關于需求規劃最后多說一點。Docker Swarm 和 Docker UCP 簡化了管理節點和工作節點的添加 / 刪除工作。新加入的管理節點被自動加入到 HA 控制平面，新加入的工作節點馬上就能參與到工作負載調度當中。

類似的，刪除管理節點和工作節點也非常簡單。只要擁有多個管理節點，就可以在不影響集群操作的情況下移除其中一個。移除工作節點時，需要清理該節點上的工作負載，然后從運行中的集群移除。上述特點使得 UCP 對管理節點和工作節點的變更做到不感知。

安裝 Docker UCP

下面主要介紹在新集群的第一個管理節點上安裝 Docker UCP 的完整過程。

⒈ 在某個 Linux Docker EE 節點上運行下面的命令，該節點應是計劃中作為 UCP 集群的第一個管理節點。

關于命令需要補充說明，示例在安裝 UCP 時，使用了 docker/ucp:2.2.5 鏡像，用戶需要替換為適合自己的版本。--host-address 設置了 Web 界面訪問地址。如果用戶在 AWS 上完成安裝，并且計劃通過互聯網訪問公司的網絡，這里就需要設置 AWS 的公共 IP 地址。

$ docker container run --rm -it --name ucp \
-v /var/run/docker.sock:/var/run/docker.sock \
docker/ucp:2.2.5 install \
--host-address <node-ip-address> \
--interactive

⒉ 配置管理員賬號。安裝過程會提示用戶輸入用戶名和密碼，作為 UCP 管理員賬號。這是一個本地賬號，建議遵守公司規范來創建用戶名和密碼。創建后千萬不要忘記。

⒊ 主體別名(Subject Alternative Name，SAN)。安裝程序會提示輸入能訪問 UCP 的 IP 地址和名稱列表。列表內容可以是私有 IP 地址以及 DNS 名稱，并且會加入到賬號當中。

安裝過程還需注意以下的一些內容。

UCP 基于 Docker Swarm，這意味著 UCP 管理節點需要運行在 Swarm 管理節點上。如果在某個節點上以單引擎模式(Single-Engine Mode)安裝 UCP，則該節點會默認切換為 Swarm 模式。

安裝程序拉取 UCP 服務所需的全部鏡像，并完成相應容器的啟動。下面列舉了部分由安裝程序拉取的鏡像。

INFO[0008] Pulling required images... (this may take a while)
INFO[0008] Pulling docker/ucp-auth-store:2.2.5
INFO[0013] Pulling docker/ucp-hrm:2.2.5
INFO[0015] Pulling docker/ucp-metrics:2.2.5
INFO[0020] Pulling docker/ucp-swarm:2.2.5
INFO[0023] Pulling docker/ucp-auth:2.2.5
INFO[0026] Pulling docker/ucp-etcd:2.2.5
INFO[0028] Pulling docker/ucp-agent:2.2.5
INFO[0030] Pulling docker/ucp-cfssl:2.2.5
INFO[0032] Pulling docker/ucp-dsinfo:2.2.5
INFO[0080] Pulling docker/ucp-controller:2.2.5
INFO[0084] Pulling docker/ucp-proxy:2.2.5

部分比較值得關注的鏡像包括以下幾點。

? ucp-agent 這是 UCP 核心代理。該代理會部署到集群的全部節點上，用于確保 UCP 所需容器全部啟動并運行。

? ucp-etcd 集群持久化鍵值對存儲。

? ucp-auth 共享鑒權服務(在 DTR 的單點登錄中也用到了)。

? ucp-proxy 控制對本地 Docker Socket 端口的訪問，這樣未認證的客戶端就不能擅自篡改集群了。

? ucp-swarm 提供對底層 Swarm 的適配。

最終，安裝程序創建了一對根 CA：一個用于集群內部通信，另一個用于外部訪問。CA 使用自簽名證書，這對于實驗和測試環境來說很好，但是不適用于生產環境。

為了完成可信 CA 證書的 UCP 安裝，需要使用下面 3 個文件完成證書綁定。

? ca.pem：可信 CA 證書(通常是公司內部 CA)。

? cert.pem：UCP 的公開證書。該證書包含了全部被授權訪問集群的 IP 地址和 DNS 名稱，包括位于集群之前的負載均衡器。

? key.pem：UCP 的私鑰。

如果已經有了上述文件，則需要將其掛載到 Dockerucp-controller-server-certs 卷下，并且使用 --external-ca 數指定卷。用戶也可以在安裝完成后，通過 Web 界面中的管理員設置(Admin Setting)頁面來修改證書。

UCP 安裝程序輸出中的最后一段內容，就是訪問所用的 URL。

<Snip>
INFO[0049] Login to UCP at https://<IP or DNS>:443

通過 Web 瀏覽器訪問該地址并且登錄。如果使用自簽名證書，則需要確認瀏覽器的告警信息。同時還需要指定許可證文件，該文件可以從 Docker 商店的 My Content 中下載。

登錄后即可訪問 UCP 管理面板，如下圖所示。

到目前為止，一個單點登錄 UCP 集群已經就緒。

可以通過管理面板底部的 Add Nodes 鏈接為集群添加更多的管理節點和工作節點。

下圖展示了添加節點的界面。用戶可以選擇添加管理節點或者工作節點，然后界面中就會給出對應的命令，在待添加節點上運行即可。示例中選擇添加 Linux 工作節點。注意，這是一個 docker swarm命令。

添加的節點會加入 Swarm 集群，并且配置所需的 UCP 服務。如果添加的是管理節點，推薦在連續添加之間稍作等待。這樣可以給 Docker 留出下載并運行所需 UCP 容器的機會，同時也允許集群注冊新的管理節點并達到法定人數。

新加入的管理節點會自動配置到高可用(HA)的一致性 Raft 組當中，并且被授權可以訪問集群存儲。此外，雖然外部負載均衡器通常不被認作 UCP HA 的核心部分，但其本身對外提供了穩定的 DNS 名稱，屏蔽了一些后端場景，如某個節點掛掉。

用戶需要為 443 端口的 TCP 透傳配置外部的負載均衡器，通過自定義的 HTTPS 心跳檢查 https:///_ping 確認 UCP 管理節點的狀態。

現在一個工作狀態的 UCP 已經搭建完成，可以通過 Admin Settings 頁面查看相關選項，如下圖所示。

UCP 的訪問控制

所有對 UCP 的訪問，都經由身份管理子系統。這意味著用戶在集群上執行任何操作前，首先需要通過用戶名和密碼進行認證。這些操作包括集群的管理，以及服務的部署和管理。

用戶使用 UI 界面的時候已經體驗過了，必須使用用戶名和密碼才能登錄。在 CLI 中也是一樣的，用戶不能在未登錄的情況下通過 UCP 執行命令!這是因為 UCP 集群中本地 Docker Socket 受到 ucp-proxy 服務的保護，不會接受未認證命令。

客戶端綁定

每個運行 Docker CLI 的節點，都能部署并管理 UCP 集群的工作負載，只要該節點存在一個有效 UCP 用戶認證。

本節中會創建一個新 UCP 用戶，新建并下載該用戶的綁定證書，接著創建一個 Docker 客戶端并使用該證書。在完成上述步驟后，會解釋其工作原理。

⒈ 如果還沒就緒，則以管理員身份登錄 UCP。

⒉ 單擊 User Management > Users，創建一個新用戶。因為還未討論角色和權限相關的內容，所以將用戶設置為 Docker EE 管理員。

⒊ 在新用戶選中狀態下，單擊 Configure 下拉框，然后選擇 Client Bundle，如下圖所示。

⒋ 單擊 Client Bundle +鏈接，生成并下載該用戶的客戶端 Bundle。

此時需要注意，客戶端 Bundle 是與用戶相關的。因此，該 Bundle 能夠使得配置好的 Docker 客戶端在 UCP 集群上以該 Bundle 所屬用戶的身份執行命令。

⒌ 復制下載內容到 Docker 客戶端，該客戶端是用戶配置用于管理 UCP 的。

⒍ 登錄客戶端節點，執行下面的全部命令。

⒎ 解壓縮客戶端綁定內容。

$ unzip ucp-bundle-nigelpoulton.zip
Archive: ucp-bundle-nigelpoulton.zip
extracting: ca.pem
extracting: cert.pem
extracting: key.pem
extracting: cert.pub
extracting: env.sh
extracting: env.ps1
extracting: env.cmd

示例使用 Linux 的 unzip 包將客戶端綁定解壓縮到當前目錄。需要將命令中客戶端綁定的名稱替換為自己環境中的名稱。

⒏ 使用恰當的腳本配置 Docker 客戶端。env.sh 可以在 Linux 和 Mac 上使用，env.ps 和 env.cmd 可以在 Windows 上使用。

運行腳本需要管理員 /root 權限。示例在 Windows 和 Linux 上均可以執行。

$ eval "$(<env.sh)"

此時，客戶端節點配置已經完成。

⒐ 測試權限。

$ docker version

<Snip>

Server:
Version: ucp/2.2.5
API version: 1.30 (minimum version 1.20)
Go version: go1.8.3
Git commit: 42d28d140
Built: Wed Jan 17 04:44:14 UTC 2018
OS/Arch: linux/amd64
Experimental: false

注意到輸出中的 Server 部分顯示其版本為 ucp/2.2.5，這就說明 Docker 客戶端已經成功連接到 UCP 節點的 daemon 了。

實際上，腳本共配置了 3 個環境變量：DOCKER_HOST、DOCKER_TLS_VERIFY 和 DOCKER_CERT_PATH。

DOCKER_HOST 將客戶端指向了遠端位于 UCP 控制層中的 Docker daemon。比如 DOCKER_HOST=tcp://34.242.196.63:443，可以看到，是通過 443 端口訪問的。

DOCKER_TLS_VERIFY 設置為 1，告訴客戶端使用 TLS 認證的客戶端模式。DOCKER_CERT_PATH 告訴 Docker 客戶端綁定證書的具體位置。

最終結果就是所有 Docker 命令都會在客戶端使用用戶證書簽名，然后經由網絡發送到遠端的 UCP 管理節點，如下圖所示。

UCP 備份

首先并且最重要的是，高可用(HA)并不等價于備份!

思考下面的例子。有一個包含 5 個管理節點的 UCP 集群。所有管理節點都處于健康狀態，并且控制平面開啟了復制功能。某個心懷怨恨的員工對集群進行破壞(或者刪除了全部用戶賬戶)。破壞操作會復制到全部 5 個管理節點，導致集群被破壞。這種場景下 HA 沒有絲毫幫助。此時需要的，是備份!

一個 UCP 集群主要由 3 個部分構成，也是需要分別備份的內容：Swarm、UCP 和 Docker 可信鏡像倉庫服務(DTR)。

接下來會展示如何完成 Swarm 和 UCP 的備份，有關 DTR 備份的內容本章會在稍后進行介紹。

雖然 UCP 位于 Swarm 上層，但是它們是互相獨立的。Swarm 維護了全部節點關系、網絡以及服務定義。UCP 在其上層構建，維護自己的數據庫和卷存儲來記錄用戶、組、授權、Bundle、許可證文件、認證等信息。

一起來看一下如何進行 Swarm 備份。

Swarm 配置和狀態保存在 /var/lib/docker/swarm 中，其中包含了 Raft 日志密鑰，并且會復制到每個管理節點。Swarm 備份就是復制該目錄下的所有文件。

因為該信息會復制到每個管理節點，所以用戶可以在任何管理節點上進行備份。

備份時需要在待執行備份操作的節點上停止 Docker。這意味著在主管理節點上執行備份操作不是一個好的選擇，因為這樣會導致重新選主。

執行備份時最好選擇在業務的低峰期進行，雖然對于擁有多管理節點的 Swarm 來說，停止某個管理節點并不會出現問題，但這種操作還是會增加集群在另一管理節點宕機時出現高可用有效節點數不足的情況。

在執行備份前，創建一些 Swarm 對象可以驗證備份和回滾操作是否確實生效了。示例中待備份的 Swarm，擁有一個名為 vantage-net 的覆蓋網絡，以及名為 vantage-svc 的 Swarm 服務。

⒈ 停止待備份 Swarm 管理節點上的 Docker。這樣會停止該節點上的全部 UCP 容器。如果 UCP 配置了 HA，則其他管理節點會保證控制平面處于可用狀態。

$ service docker stop

⒉ 備份 Swarm 配置。示例使用 Linux tar 工具來執行文件復制?？呻S意選擇其他工具。

$ tar -czvf swarm.bkp /var/lib/docker/swarm/
tar: Removing leading `/' from member names
/var/lib/docker/swarm/
/var/lib/docker/swarm/docker-state.json
/var/lib/docker/swarm/state.json
<Snip>

⒊ 確認備份文件存在。

$ ls -l
-rw-r--r-- 1 root root 450727 Jan 29 14:06 swarm.bkp

備份文件的保存周期需要視公司具體的備份策略而定。

⒋ 重啟 Docker。

$ service docker restart

現在 Swarm 備份完成，是時候備份 UCP 了。在開始 UCP 備份前，需要注意如下幾點。

因為 UCP 備份任務以容器方式運行，所以如果想進行備份，需要 Docker 保持運行狀態。

可以在集群中的任意一臺 UCP 管理節點上運行備份，并且只需要在一個節點上運行即可(UCP 復制功能會將配置信息復制到全部管理節點，所以沒有必要備份多節點)。

對 UCP 進行備份會停止所在管理節點上的全部 UCP 容器。在該前提下，備份操作需要運行在一個高可用 UCP 集群上，并且最好是在業務低峰期運行。

自始至終，執行備份的管理節點上的用戶工作負載并不會停止。但是，并不建議在 UCP 管理節點上執行用戶工作負載。

下面開始備份 UCP。在某個 UCP 管理節點上執行下面的命令。該節點的 Docker 需要保持運行狀態。

$ docker container run --log-driver none --rm -i --name ucp \
-v /var/run/docker.sock:/var/run/docker.sock \
docker/ucp:2.2.5 backup --interactive \
--passphrase "Password123" > ucp.bkp

該命令很長，一起來看一下每個步驟的內容。

第一行是標準的 docker container run 命令，讓 Docker 運行某個容器，運行時不開啟日志，在運行結束后進行刪除，同時調用 ucp;第二行將 Docker socket 掛載到容器中，這樣容器可以通過訪問 Docker API 來停止運行;第三行是告訴 Docker 在容器內基于 docker/ ucp:2.2.5 鏡像運行 backup --interactive 命令;最后一行創建了名為 ucp.bkp 的加密文件，并且用密碼進行安全保護。

下面是值得注意的幾點。

指定具體的 UCP 鏡像版本(標簽)是一個好辦法，示例中指定為 docker/ucp:2.2.5。這樣做是因為進行備份和恢復操作的時候，建議使用相同版本的鏡像。如果沒有顯示指定鏡像版本，Docker 會默認使用標簽為 latest 的鏡像，這可能導致執行備份和恢復操作時鏡像版本存在差異。

每次備份都應當使用 --passphrase 來保護備份內容，此外可以改進示例中的密碼，使其對用戶更加友好。

建議根據用戶的備份要求對備份文件進行目錄化管理，并保存一個離線備份。此外建議配置備份計劃和對應的檢查任務。

現在已經完成了 Swarm 和 UCP 的備份，可以在災難性事件發生后安全地進行恢復了。

恢復 UCP

在介紹恢復 UCP 之前，有句話不得不提前說明：從備份進行恢復是最后的手段，只能在整個集群都宕機或者全部管理節點都丟失的情況下使用!

如果 HA 集群下僅丟失某個管理節點，并不需要從備份進行恢復。該情況下，很容易就能創建新管理節點并加入集群。

下面會先介紹如何從備份恢復 Swarm，然后是 UCP。

在欲恢復的 Swarm/UCP 管理節點上執行下面的任務。

⒈ 停止 Docker。

$ service docker stop

⒉ 刪除全部已存在的 Swarm 配置。

$ rm -r /var/lib/docker/swarm

⒊ 從 Swarm 備份中恢復配置信息。

示例中使用了名為 swarm.bkp 的壓縮文件，格式為 tar。該命令需要指定恢復到根目錄下，因為備份文件解壓為原始文件的操作中會包含全路徑信息。

$ tar -zxvf swarm.bkp -C /

⒋ 初始化新的 Swarm 集群。

切記，當前執行的操作并不是恢復某個節點然后重新加入集群。該操作是恢復一個不可用的 Swarm 集群，其中不包含任何存活的管理節點。--force-new-cluster 參數告訴 Docker 創建新集群，使用的配置保存在當前節點 /var/lib/docker/swarm 目錄下。

$ docker swarm init --force-new-cluster
Swarm initialized: current node (jhsg...3l9h) is now a manager.

⒌ 檢查網絡和服務是恢復操作中的一部分。

$ docker network ls
NETWORK ID NAME DRIVER SCOPE
snkqjy0chtd5 vantage-net overlay swarm

$ docker service ls
ID NAME MODE REPLICAS IMAGE
w9dimu8jfrze vantage-svc replicated 5/5 alpine:latest

至此，Swarm 集群完成恢復。

⒍ 為 Swarm 集群增加新的管理節點和工作節點，并刷新備份。

在恢復 Swarm 之后，可以恢復 UCP。在示例中，UCP 備份到了當前目錄下名為 ucp.bkp 的文件中。雖然文件名是備份文件，但其本質是一個 Linux 打包工具。

在欲恢復 UCP 的節點上執行下面的命令。該節點可以是剛剛執行 Swarm 恢復操作的節點。

⒈ 刪除已經存在并且可能崩潰的 UCP 安裝。

$ docker container run --rm -it --name ucp \
-v /var/run/docker.sock:/var/run/docker.sock \
docker/ucp:2.2.5 uninstall-ucp --interactive

INFO[0000] Your engine version 17.06.2-ee-6, build e75fdb8 is compatible
INFO[0000] We're about to uninstall from this swarm cluster.
Do you want to proceed with the uninstall? (y/n): y
INFO[0000] Uninstalling UCP on each node...
INFO[0009] UCP has been removed from this cluster successfully.
INFO[0011] Removing UCP Services

⒉ 從備份中恢復 UCP。

$ docker container run --rm -i --name ucp \
-v /var/run/docker.sock:/var/run/docker.sock \
docker/ucp:2.2.5 restore --passphrase "Password123" < ucp.bkp

INFO[0000] Your engine version 17.06.2-ee-6, build e75fdb8 is compatible
<Snip>
time="2018-01-30T10:16:29Z" level=info msg="Parsing backup file"
time="2018-01-30T10:16:38Z" level=info msg="Deploying UCP Agent Service"
time="2018-01-30T10:17:18Z" level=info msg="Cluster successfully restored.

⒊ 登錄 UCP Web 界面，確認之前創建的用戶還存在(或者是任何之前環境中存在的 UCP 對象)。