如何理解企業級容器Registry開源項目Harbor架構

這篇文章將為大家詳細講解有關如何理解企業級容器Registry開源項目Harbor架構，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

1. Harbor項目

VMware公司最近開源了企業級Registry項目Harbor，由VMware中國研發的團隊負責開發。Harbor項目是幫助用戶迅速搭建一個企業級的registry 服務。它以Docker公司開源的registry為基礎，提供了管理UI, 基于角色的訪問控制(Role Based Access Control)，鏡像遠程復制（同步），AD/LDAP集成、以及審計日志(Audit logging) 等企業用戶需求的功能，同時還原生支持中文，對廣大中國用戶是一個好消息。本文將介紹Harbor項目的主要組件，并闡述Harbor的工作原理。

（源代碼地址：https://github.com/vmware/harbor ）

2.架構介紹

1)    主要組件

Harbor在架構上主要由6個組件構成：

·      Proxy：Harbor的registry, UI, token等服務，通過一個前置的反向代理統一接收瀏覽器、Docker客戶端的請求，并將請求轉發給后端不同的服務。

·      Registry： 負責儲存Docker鏡像，并處理docker push/pull 命令。由于我們要對用戶進行訪問控制，即不同用戶對Docker image有不同的讀寫權限，Registry會指向一個token服務，強制用戶的每次docker pull/push請求都要攜帶一個合法的token, Registry會通過公鑰對token 進行解密驗證。

·      Core services： 這是Harbor的核心功能，主要提供以下服務：

o   UI：提供圖形化界面，幫助用戶管理registry上的鏡像（image）, 并對用戶進行授權。

o   webhook：為了及時獲取registry 上image狀態變化的情況， 在Registry上配置webhook，把狀態變化傳遞給UI模塊。

o   token 服務：負責根據用戶權限給每個docker push/pull命令簽發token. Docker 客戶端向Regi?stry服務發起的請求,如果不包含token，會被重定向到這里，獲得token后再重新向Registry進行請求。

·      Database：為core services提供數據庫服務，負責儲存用戶權限、審計日志、Docker image分組信息等數據。

       Job Services：提供鏡像遠程復制功能，可以把本地鏡像同步到其他Harbor實例中。

·      Log collector：為了幫助監控Harbor運行，負責收集其他組件的log，供日后進行分析。

各個組件之間的關系如下圖所示：

2)    實現

Harbor的每個組件都是以Docker 容器的形式構建的，因此很自然地，我們使用Docker Compose來對它進行部署。

在源代碼中(https://github.com/vmware/harbor), 用于部署Harbor的Docker Compose 模板位于 /Deployer/docker-compose.yml. 打開這個模板文件，會發現Harbor由5個容器組成：

·      proxy: 由Nginx 服務器構成的反向代理。

·      registry:由Docker官方的開源registry 鏡像構成的容器實例。

·      ui: 即架構中的core services, 構成此容器的代碼是Harbor項目的主體。

·      mysql: 由官方MySql鏡像構成的數據庫容器。

       job services: 通過狀態機機制實現遠程鏡像復制功能，包括鏡像刪除也可以同步到遠端Harbor實例。

·      log: 運行著rsyslogd的容器，通過log-driver的形式收集其他容器的日志。

這幾個容器通過Docker link的形式連接在一起，這樣，在容器之間可以通過容器名字互相訪問。對終端用戶而言，只需要暴露proxy （即Nginx）的服務端口。

3. 工作原理

下面以 兩個Docker 命令為例，講解主要組件之間如何協同工作。

1.  docker login

假設我們將Harbor部署在IP 為192.168.1.10的虛機上。用戶通過docker login命令向這個Harbor服務發起登錄請求：

# docker login 192.168.1.10

當用戶輸入所需信息并點擊回車后，Docker 客戶端會向地址 “192.168.1.10/v2/” 發出HTTP GET請求。 Harbor的各個容器會通過以下步驟處理：

(a) 首先，這個請求會由監聽80端口的proxy容器接收到。根據預先設置的匹配規則， 容器中的Nginx會將請求轉發給后端的registry 容器；

(b) 在registry容器一方，由于配置了基于token的認證，registry會返回錯誤代碼401，提示Docker客戶端訪問token服務綁定的URL。在Harbor中，這個URL指向Core Services；

(c) Docker  客戶端在接到這個錯誤代碼后，會向token服務的URL發出請求，并根據HTTP協議的Basic Authentication規范，將用戶名密碼組合并編碼，放在請求頭部(header)；

(d)類似地，這個請求通過80端口發到proxy容器后，Nginx會根據規則把請求轉發給ui容器，ui容器監聽token服務網址的處理程序接收到請求后，會將請求頭解碼，得到用戶名、密碼；

(e) 在得到用戶名、密碼后，ui容器中的代碼會查詢數據庫，將用戶名、密碼與mysql容器中的數據進行比對（注：ui 容器還支持LDAP的認證方式，在那種情況下ui會試圖和外部LDAP服務進行通信并校驗用戶名/密碼)。比對成功，ui容器會返回表示成功的狀態碼， 并用密鑰生成token，放在響應體中返回給Docker 客戶端。

這個過程中組件間的交互過程如下圖所示:

至此，一次docker login 成功地完成了，Docker客戶端會把步驟(c)中編碼后的用戶名密碼保存在本地的隱藏文件中。

2.   docker push

用戶登錄成功后用docker push命令向Harbor 推送一個Docker image：

# docker push 192.168.1.10/library/hello-world

(a) 首先，docker 客戶端會重復login的過程，首先發送請求到registry,之后得到token 服務的地址；

(b) 之后，Docker 客戶端在訪問ui容器上的token服務時會提供額外信息，指明它要申請一個對image library/hello-world進行push操作的token；

(c) token 服務在經過Nginx轉發得到這個請求后，會訪問數據庫核實當前用戶是否有權限對該image進行push。如果有權限，它會把image的信息以及push動作進行編碼，并用私鑰簽名，生成token返回給Docker客戶端；

(d) 得到token之后 Docker客戶端會把token放在請求頭部，向registry發出請求，試圖開始推送image。 Registry 收到請求后會用公鑰解碼token并進行核對，一切成功后，image的傳輸就開始了。

 我們省去proxy轉發的步驟，下圖描述了這個過程中各組件的通信過程：

關于如何理解企業級容器Registry開源項目Harbor架構就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。