本文講的是<b>DockOne微信分享（七十七）：用Harbor實作容器鏡像倉庫的管理和運維</b>【編者的話】本次分享主要講述了在開發運維中的管理容器鏡像方法。為了便于說明原理，較多地使用Harbor作為例子。
内容主要包括：
開發和生産環境中鏡像倉庫的權限控制；
鏡像遠端同步（複制）的原理；
大規模應用鏡像釋出方式；
鏡像删除和空間回收；
Registry高可用性設計。
容器應用的使用越來越普遍，容器最大優點就是開發運維一體化，通過容器鏡像打包應用，使得開發、測試和釋出都具有相同的運作環境，帶來極大的便利。那麼鏡像在實際運維中處于怎樣的地位呢？
我們先看看下面這張經典的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高可用性（HA）是多數生産系統需要關心的問題，基本要求就是沒有單點故障。通常需要根據允許服務中斷的時間，以及可以承受的成本和損失，來确定采用的技術。下面介紹3種HA的方案：
一種比較标準的方案，就是多個的Registry執行個體共享同一個後端存儲，任何一個執行個體持久化到存儲的鏡像，都可被其他執行個體中讀取。通過前置LB進來的請求，可以分流到不同的執行個體中去處理，實作了負載均衡，也避免了單點故障。
應該指出，實際中需要考慮的問題遠比上述模型複雜。例如，共享存儲的選取，使用者Session在不同的執行個體上共享等等。使用者可根據自己業務要求設計出不同的方案。Harbor将會推出基于Swift分布式存儲，以及共享Session的方案（采用Redis）來滿足使用者的需求。
如果沒有共享存儲，另一種方案就是在兩個節點間采用雙主複制政策，互相複制鏡像。即使有一個執行個體失效，另一個執行個體仍然可以提供服務，進而在一定程度上可以滿足HA的需求。
第3中方案是利用已有的HA平台，如vSphere HA，配合分布式存儲VSAN，可以實作Harbor的HA，具體架構見下圖：
節點出現故障的時候，有vSphere自動切換到好的節點上，鏡像資料不丢失。
Q：Master-Slave的鏡像架構中,如果Slave Registy中的鏡像被删除了，會不會再次自動從Master Reg裡面自動同步？
A：如果停止後再重新啟動複制政策，可以同步被删除的鏡像。
Q：對于多個投産地，多個倉庫，哪種方式的高可用方案好麼？第一種，共享存儲存儲可能會出現單點故障麼？
A：共享存儲隻适合同一資料中心，多個産地延時太大，不适合共享存儲。
Q：Registry之間同步是如何實作的？
A：Registry API。
Q：在存儲這塊考慮過提供插件方式可以調用外部子產品，比如以插件方式支援s3這種對象存儲？
以上内容根據2016年8月18日晚微信群分享内容整理。分享人張海甯（Henry Zhang），VMware中國研發中心雲原生應用首席架構師，Harbor開源企業級容器Registry項目負責人，Cloud Foundry中國社群最早的技術布道師之一。在VMware中國研發中心先後負責開源平台Cloud Foundry、大資料虛拟化、軟體定義存儲等領域的技術布道和解決方案推廣。目前着重關注雲原生應用的研發工作，内容包括Container、PaaS、IaaS等方面。DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加微信：liyingjiesz，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。
原文釋出時間為：2016-08-21
本文作者：張海甯
本文來自雲栖社群合作夥伴Dockerone.io，了解相關資訊可以關注Dockerone.io。
原文标題：DockOne微信分享（七十七）：用Harbor實作容器鏡像倉庫的管理和運維