用Harbor實現容器鏡像倉庫的管理和運維

(本文由8月18日VMware中國研發首席架構師張海寧在Harbor技術羣分享內容彙編而成。)

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

內容主要包括：
1）開發和生產環境中鏡像倉庫的權限控制
2）鏡像遠程同步（複製）的原理
3）大規模應用鏡像發佈方式；
4）鏡像刪除和空間回收
5）Registry高可用性設計。

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

容器應用的使用愈來愈廣泛，容器最大優勢就是開發運維一體化，經過容器鏡像打包應用，使得開發、測試和發佈都具備相同的運行環境，帶來極大的便利。那麼鏡像在實際運維中處於怎樣的地位呢？

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

從圖中能夠看到，容器鏡像的關聯箭頭最多，不言而喻，鏡像技術就是容器的核心所在。歸納地說，容器包含一靜一動兩部分：靜態存放的鏡像(images)和動態運行的containers。相應地，容器的開發運維主要涉及鏡像管理和運行時(Runtime)管理兩部分。本文主要和你們分享的是容器鏡像管理的部分。

1）開發和生產環境中鏡像倉庫的權限控制

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

例如，測試人員一般只須要鏡像的讀權限(pull)，開發人員須要讀寫權限(push/pull)，項目經理除了擁有開發人員的權限以外，還能夠增長和刪除項目成員，設定他們的角色。
在Harbor Registry中，每一個項目可有三種角色：項目管理員(project admin)、開發者(developer)和客人(guest)。某些項目，如放在library中的公共鏡像, 能夠容許匿名訪問，即用戶不一樣docker login也能夠訪問，這樣能夠方便使用。在整個系統中，還設有系統管理員，具備維護鏡像同步策略、用戶增刪等權限。

須要指出的是，在不一樣的環境中，某個成員的角色能夠不一樣。例如，在開發環境的registry中，運維人員通常不須要權限（或須要只讀權限）；而在生產環境中的Registry，運維人員就須要有讀寫權限。下圖是Harbor的權限管理界面：

2）鏡像遠程同步（複製）的原理
不少用戶在開發、測試和運維中都使用同一個Registry，這樣「簡單粗暴」的方式比較適合小團隊或簡單的項目，其餘狀況最好使用多個Registry以區分不一樣的用途。以下圖，容器鏡像管理的參考流程。

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

測試環境的Registry: 主要由測試人員使用，鏡像保持不變。當測試經過後，同步到準生產環境的Registry;

準生產環境的Registry: 主要由測試和運維人員使用，鏡像保持不變。當準生產環境試運行後，最後再同步生產環境的Registry;

生產環境的Registry: 發佈鏡像到生產環境運行。

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

3）大規模應用鏡像發佈方式；

在實際生產運維的中，每每須要把鏡像發佈到幾十或上百臺集羣節點上。這時，單個Registry已經沒法知足大量節點的下載需求，所以要配置多個registry實例作負載均衡。手工維護多個registry實例上的鏡像，將是十分繁瑣的事情。Harbor能夠支持一主多從的鏡像發佈模式，能夠解決大規模鏡像發佈的難題。

只要往一臺registry上發佈，鏡像就像「仙女散花」般地同步到多個registry中，高效可靠。

若是是地域分佈較廣的集羣，還能夠採用層次型發佈方式，如從集團總部同步到省公司，從省公司再同步到市公司：

在同步過程當中，若是源鏡像已刪除，Harbor會自動同步刪除遠端的鏡像。在鏡像同步複製的過程當中，Harbor會監控整個複製過程，遇到網絡等錯誤，會自動重試。

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

4）鏡像刪除和空間回收
Docker命令沒有提供Registry鏡像刪除功能，日積月累，將會產生許多無用的鏡像，佔用大量存儲空間。若要刪除鏡像並回收空間，須要調用docker registry API來完成，比較麻煩。Harbor提供了可視化的鏡像刪除界面，能夠邏輯刪除鏡像。在維護狀態下能夠回收垃圾鏡像的空間。

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

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

應該指出，實際中須要考慮的問題遠比上述模型複雜。例如，共享存儲的選取，用戶session在不一樣的實例上共享等等。用戶可根據本身業務要求設計出不一樣的方案。Harbor將會推出基於swift分佈式存儲，以及共享session的方案（採用redis）來知足用戶的需求。

若是沒有共享存儲，另外一種方案就是在兩個節點間採用雙主複製策略，互相複製鏡像。即便有一個實例失效，另外一個實例仍然能夠提供服務，從而在必定程度上能夠知足HA的需求。

第3中方案是利用已有的HA平臺，如vSphere HA，配合分佈式存儲VSAN，能夠實現Harbor的HA, 具體架構見下圖：

節點出現故障的時候，有vSphere自動切換到好的節點上，鏡像數據不丟失。

咱們以開源Harbor爲例子，總結了Registry的使用場景和要點，但願對你們有幫助。

歡迎廣大用戶使用Harbor項目並反饋意見和建議，也歡迎加入咱們貢獻代碼。若是您是Harbor的用戶或開發者，可申請加入Harbor開源項目微信羣，以方便溝通。請先掃描下面二維碼關注「亨利筆記」公衆號，並在公衆號後臺發送"入羣"信息便可。