企業級Docker鏡像倉庫的管理和運維

DianneBorde 8年前發布 | 11K 次閱讀運維技術 Docker

容器應用的使用越來越廣泛，容器技術突出的優點就是開發運維一體化。通過把應用及其所依賴的軟件包、操作系統文件等封裝在容器鏡像中，使得應用在開發、測試和發布過程中都具有相同的運行環境，帶來極大的便利。從圖1這張經典的Docker容器狀態轉換圖可以看到，容器鏡像(images)的關聯箭頭最多，不言而喻，鏡像就是容器技術的核心所在。

圖1 Docker容器狀態轉換圖

概括地說，容器技術包含一靜一動兩部分：封裝應用的靜態鏡像(images)和運行應用的動態容器(containers)。相應地，容器的開發運維主要涉及鏡像管理和運行時(Runtime)管理兩部分。本文主要和大家談談容器鏡像管理的部分。

容器鏡像的管理主要圍繞鏡像倉庫(registry)來進行。在應用的生命周期中，無論開發人員或CI系統發布鏡像，還是測試人員或運維人員下載鏡像，都要通過鏡像倉庫來完成。鏡像倉庫可以使用公有的SaaS服務，例如Docker Hub。公有服務的優點是可直接使用，無需自己維護。但考慮到訪問效率和鏡像安全等方面的原因，大多數公司都建立了自己的私有鏡像倉庫(Registry)，因此也需要有貫穿整個應用生命周期的鏡像管理策略。

下文主要介紹在開發運維中的管理容器鏡像原理和方法，為了便于說明原理，較多地使用Harbor作為例子。Harbor是由VMware中國研發團隊負責開發的開源企業級Registry，可幫助用戶迅速搭建企業級的registry 服務，提供權限控制、鏡像同步、中文管理界面等強大功能，深受廣大用戶喜愛。有興趣的朋友可以關注或使用： https://github.com/vmware/harbor 。

確保鏡像內容的一致性

在應用的開發、測試和運行等各個階段，需要確保都使用同一個應用的鏡像。一種做法是在每個階段都用相同dockerfile去生成所需鏡像。通常認為，相同的dockerfile可以構件出相同的鏡像，而實際上卻并非如此。例如下面的dockerfile 部分：

FROM ubuntu

RUN apt-get install –y python

ADD app.jar /myapp/app.jar

首先，FROM的基礎鏡像隱含使用了latest版本，在不同時間構建的鏡像，可能是不同的版本。即使指明了ubuntu:14.04這樣的版本號也不保險，因為相同版本的系統可能含有補丁等不盡相同的軟件包。

再看apt-get這樣的命令(類似的還有curl，wget等)，往往會從互聯網上引入第三方的軟件包，版本的一致性就更加無從確定了。還有在ADD語句中添加到鏡像里面的文件app.jar，取決于構建時的文件版本，也是一個不確定的因素。

從上面的例子可以看到，盡管docker鏡像的目的是構造不可更改的應用環境，但由于其構建的時候往往具有不確定的輸入，相同dockerfile生成的鏡像未必包含相同的內容。因此，最好的方法還是在不同的環境中始終采用相同的鏡像(二進制格式)，雖然在傳輸量上比dockerfile要大，但是可以確保鏡像的一致性。

鏡像的傳輸

很多用戶在開發、測試和運維中都使用同一個Registry作為鏡像倉庫，這種方式比較適合小團隊或簡單的項目。在其他情況下，最好使用多個Registry以區分不同的用途和安全控制要求。容器鏡像管理的參考流程(如圖2所示)。

圖2 應用鏡像的管理流程

開發環境的Registry: 主要由開發人員使用，鏡像變化頻繁。當開發完成后，通過CI系統生成穩定鏡像，并同步到測試Registry;

測試環境的Registry: 主要由測試人員使用，鏡像保持不變。當測試通過后，鏡像推送到準生產環境的Registry;

準生產環境(Staging)的Registry: 主要由測試和運維人員使用，鏡像保持不變。當準生產環境試運行后平穩后，再發布到生產環境的Registry;

生產環境的Registry: 發布鏡像到生產環境的節點運行。

從開發到生產的整個過程中，符合要求的容器鏡像會逐步進入下一級的Registry，最后到達生產系統，從而實現容器鏡像的構建-傳輸-運行(Build-Ship-Run)過程。

Harbor提供Registry之間的鏡像自動同步和復制功能，通過配置復制策略，自動化管理鏡像傳輸流程。Harbor的復制策略啟動之后，會比較目標Registry和本地源Registry在鏡像上的差異，并把目標Registry缺少的鏡像從本地推送過去，使得兩個Registry實例的鏡像完全一致。后續推送到源實例上的鏡像，會以增量的形式同步到目標實例上。當在源實例上刪除鏡像的時候，目標實例上的鏡像也會被刪除。通過Harbor的復制機制，可實現兩個或多個registry實例之間的鏡像同步。

鏡像的權限控制

在企業中，通常有不同的開發團隊來負責不同的應用項目，和源代碼分項目管理一樣，鏡像也需要按照項目來存放和管理。由于項目團隊中有不同的成員，如項目經理、產品經理、開發、測試和運維等人員，每種人員使用鏡像的需求不同，因此可以根據角色分配相應的權限。

例如，測試人員通常只需要鏡像的讀權限(pull)，開發人員需要讀寫權限(push/pull)，項目經理除了擁有開發人員的權限之外，還可以增加和刪除項目成員，設定他們的角色。

在Harbor Registry中，每個項目中可有三種角色：項目管理員(project admin)、開發者(developer)和客人(guest)。某些項目，如放在library中的公共鏡像, 可以允許匿名訪問，即用戶不用docker login也可以訪問，這樣方便某些場景的使用。在整個系統中，還設有系統管理員，具有維護鏡像同步策略、用戶增刪等權限。

需要指出的是，在不同的環境中，某個成員的角色可以不同。例如，在開發環境的registry中，運維人員一般不需要權限(或只需要讀權限);而在生產環境中的Registry，運維人員就需要有讀寫權限。

大規模鏡像發布方式

在實際生產運維的中，往往需要把鏡像發布到幾十、上百臺或更多的集群節點上。這時，單個Registry已經無法滿足大量節點的下載需求，因此要配置多個registry實例做負載均衡。手工維護多個registry實例上的鏡像，將是十分繁瑣的事情。Harbor支持一主多從的鏡像發布模式，可以解決大規模鏡像發布的難題。

圖3 主從模式的鏡像分發

如圖3所示，只要往一臺registry上發布，鏡像就像“仙女散花”般地同步到多個registry中。

如果是地域分布較廣的多數據中心或跨云的集群，還可以采用層次型發布方式，如從集團總部同步到省公司，從省公司再同步到市公司(如圖4所示)：

圖4 多級主從模式的鏡像分發

在同步過程中，如果源鏡像已刪除，Harbor會自動同步刪除遠端的鏡像。在鏡像同步復制的過程中，Harbor會監控整個復制過程，遇到網絡等錯誤，會自動重試。

同步復制的監控畫面如圖5所示：

圖5 鏡像復制策略的監控

鏡像刪除和空間回收

Docker命令沒有提供Registry鏡像刪除功能，系統日積月累地運行中，將會產生許多無用的鏡像，占用大量存儲空間。若要刪除鏡像并回收空間，需要調用docker registry API來完成，非常麻煩。Harbor提供了可視化的鏡像刪除界面，可以邏輯刪除鏡像。在維護狀態下可以回收垃圾鏡像的空間。

Registry高可用性

Registry高可用性(HA)是多數生產系統需要關心的問題，基本要求就是沒有單點故障。通常需要根據允許服務中斷的時間，以及可以承受的成本和損失，來確定采用的技術。下面介紹3種不同的高可用參考方案。