本次分享主要講述了在開發運維中的管理容器鏡像方法。為了便於說明原理，較多地使用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的需求。
