Harbor實現容器映象倉庫的管理和運維

本次分享主要講述了在開發運維中的管理容器映象方法。為了便於說明原理，較多地使用Harbor作為例子。

內容主要包括：

• 開發和生產環境中映象倉庫的許可權控制；

• 映象遠端同步（複製）的原理；

• 大規模應用映象釋出方式；

• 映象刪除和空間回收；

• Registry高可用性設計。

首先簡單介紹一下Harbor專案。Harbor是由VMware中國研發團隊負責開發的開源企業級Registry，可幫助使用者迅速搭建企業級的Registry服務。該專案釋出5多個月以來，深受使用者喜愛，在GitHub獲得了近1000個點贊星星和200多個Forks。有興趣的朋友可以使用： https://github.com/vmware/harbor

容器應用的使用越來越普遍，容器最大優點就是開發運維一體化，通過容器映象打包應用，使得開發、測試和釋出都具有相同的執行環境，帶來極大的便利。那麼映象在實際運維中處於怎樣的地位呢？

我們先看看下面這張經典的Docker容器的生命週期圖：

從圖中可以看到，容器映象的關聯箭頭最多，不言而喻，映象技術就是容器的核心所在。概括地說，容器包含一靜一動兩部分：靜態存放的映象（images）和動態執行的containers。相應地，容器的開發運維主要涉及映象管理和執行時（Runtime）管理兩部分。本文主要和大家分享的是容器映象管理的部分。

 

 

開發和生產環境中映象倉庫的許可權控制

在企業中，通常有不同的開發團隊來負責不同的應用專案，和原始碼分專案管理一樣，映象也需要按照專案來存放和管理。由於團隊中有不同的成員，如專案經理、產品經理、開發、測試和運維等人員，每人使用映象的需求不同，因此可以根據角色分配相應的許可權。

例如，測試人員通常只需要映象的讀許可權（pull），開發人員需要讀寫許可權（push/pull），專案經理除了擁有開發人員的許可權之外，還可以增加和刪除專案成員，設定他們的角色。

在Harbor Registry中，每個專案可有三種角色：專案管理員（project admin）、開發者（developer）和客人（guest）。某些專案，如放在Library中的公共映象，可以允許匿名訪問，即使用者不同Docker Login也可以訪問，這樣可以方便使用。在整個系統中，還設有系統管理員，具有維護映象同步策略、使用者增刪等許可權。

需要指出的是，在不同的環境中，某個成員的角色可以不同。例如，在開發環境的Registry中，運維人員一般不需要許可權（或需要只讀許可權）；而在生產環境中的Registry，運維人員就需要有讀寫許可權。下圖是Harbor的許可權管理介面：

 

 

映象遠端同步（複製）的原理

很多使用者在開發、測試和運維中都使用同一個Registry，這樣“簡單粗暴”的方式比較適合小團隊或簡單的專案，其他情況最好使用多個Registry以區分不同的用途。如下圖，容器映象管理的參考流程。

• 開發環境的Registry：主要由開發人員使用，映象變化頻繁。當開發完成後，通過CI系統生成穩定映象，同步到測試Registry；

• 測試環境的Registry：主要由測試人員使用，映象保持不變。當測試通過後，同步到準生產環境的Registry；

• 準生產環境的Registry：主要由測試和運維人員使用，映象保持不變。當準生產環境試執行後，最後再同步生產環境的Registry；

• 生產環境的Registry：釋出映象到生產環境執行。

從開發到生產的整個過程中，實現容器映象的Build-Ship-Run過程。Harbor可以提供Registry之間的映象自動同步和複製功能，簡化了管理。

 

大規模應用映象釋出方式

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

只要往一臺Registry上釋出，映象就像“仙女散花”般地同步到多個Registry中，高效可靠。

如果是地域分佈較廣的叢集，還可以採用層次型釋出方式，如從集團總部同步到省公司，從省公司再同步到市公司：

在同步過程中，如果源映象已刪除，Harbor會自動同步刪除遠端的映象。在映象同步複製的過程中，Harbor會監控整個複製過程，遇到網路等錯誤，會自動重試。

這是同步複製的監控畫面：

 

 

 

映象刪除和空間回收

Docker命令沒有提供Registry映象刪除功能，日積月累，將會產生許多無用的映象，佔用大量儲存空間。若要刪除映象並回收空間，需要呼叫docker registry API來完成，比較麻煩。Harbor提供了視覺化的映象刪除介面，可以邏輯刪除映象。在維護狀態下可以回收垃圾映象的空間。

 

 

Registry高可用性設計

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

一種比較標準的方案，就是多個的Registry例項共享同一個後端儲存，任何一個例項持久化到儲存的映象，都可被其他例項中讀取。通過前置LB進來的請求，可以分流到不同的例項中去處理，實現了負載均衡，也避免了單點故障。

應該指出，實際中需要考慮的問題遠比上述模型複雜。例如，共享儲存的選取，使用者Session在不同的例項上共享等等。使用者可根據自己業務要求設計出不同的方案。Harbor將會推出基於Swift分散式儲存，以及共享Session的方案（採用Redis）來滿足使用者的需求。

如果沒有共享儲存，另一種方案就是在兩個節點間採用雙主複製策略，互相複製映象。即使有一個例項失效，另一個例項仍然可以提供服務，從而在一定程度上可以滿足HA的需求。