Harbor項目概覽

Harbor項目概覽

容器應用的開發和運行離不開可靠的鏡像管理。從安全和效率等方面考慮，在企業私有環境內部署的Registry服務是非常必要的。Harbor(https://github.com/vmware/harbor)是由VMware中國研發團隊爲企業用戶設計的Registry Server開源項目，包括了權限管理(RBAC)、圖形管理界面、LDAP/AD集成、審計、自我註冊、HA等企業必需的功能，同時針對中國用戶的特點，原生支持中文，並計劃實現鏡像複製(roadmap)等功能。

本文主要介紹Harbor項目的源碼結構，幫助開發和運維人員理解其工作原理。

主要組件
Harbor系統由五個容器組成：Proxy、Core Services（包含UI, tokenservice和webhook）、Database、Registry和Log Collector。

Proxy提供反向代理服務，用戶的不同請求由Proxy分發到後端的UI或者Registry。Harbor中使用的是官方的nginx鏡像。
Core Services是Harbor項目的核心組件，主要提供權限管理、審計、管理界面UI、token service以及可供其他系統調用的API等功能。
Database提供數據持久化服務，採用了官方的mysql鏡像。
Registry是Docker官方的開源的Registry鏡像，主要提供鏡像的存儲和分發功能。
Log Collector負責收集其他容器的日誌並進行日誌輪轉。

源碼結構
以下所述主要爲Core Services組件的源碼結構，通過根目錄下的Dockerfile可以構建出Core Services的鏡像。另外Deploy目錄下的db和log分別對應Database和Log Collector的Dockerfile鏡像構建文件，而Nginx和Registry則都是採用的官方鏡像。

| – api （Harbor提供的外部調用的API）
| – auth （認證模塊，目前提供兩種方式：數據庫和LDAP）
| – db （數據庫認證）
| – ldap （LDAP認證）
| – controllers （控制器相關代碼）
| – dao （數據持久層）
| – Deploy （部署相關代碼）
| – db （構建Database鏡像的源碼）
| – log （構建Log Collector鏡像的源碼）
| – docker-compose.yml （運行Harbor的docker compose文件）
| – docs （文檔）
| – log （log工具）
| – models （數據庫映射的模型代碼）
| – routers （路由相關代碼）
| – service （服務）
| – notification.go （處理Registry發來的鏡像上傳或下載等事件）
| – token.go （爲Registry提供鑑權服務）
| – static （js、css等文件）
| – utils （工具類）
| – vendor （依賴的第三方源碼）
| – views （html模版文件）
| – Dockerfile （構建Core Services鏡像的Dockerfile）
| – main.go （入口函數）
源碼分析
下面以獲取項目列表和獲取某個項目的詳細信息爲例來分析Harbor源碼。

Harbor項目使用了go語言開發，WEB框架採用beego。main.go、routers目錄和controllers目錄分別對應了入口函數、路由函數目錄和控制器函數目錄。當Core Services啓動時，routers目錄下的相應函數會將各個控制器與其所對應的用戶請求URL進行註冊，這樣當不同的用戶請求到達的時候，不同的控制器邏輯就會被觸發。主要處理流程如下圖所示：

當獲取項目列表時會發送請求http://hostname/api/projects/，該請求首先到達Nginx。Nginx的配置文件如下：

server {
listen 80;

location / {
proxy_passhttp://ui/;
…
}

location /v1/ {
return 404;
}

location /v2/ {
proxy_passhttp://registry/v2/;
…
}

location/service/ {
proxy_passhttp://ui/service/;
…
}
}

根據配置文件該請求會被轉發到http://ui/，也即Core Services中的UI。根據UI中routers/router.go中定義的規則：

beego.Router( “/api/projects/?:id”,&api.ProjectAPI{} )

可知該請求最終是由api包中的ProjectAPI的Get方法來處理的。ProjectAPI結構體的定義如下：

typeProjectAPI struct {
BaseAPI
userID int
projectID int64
}

在beego中，控制器處理用戶請求的方法執行之前首先會執行Prepare()方法來進行一些準備或者校驗操作，ProjectAPI定義的Prepare()方法如下：

func(p *ProjectAPI) Prepare() {
p.userID = p.ValidateUser()
…
}

Prepare()中調用BaseAPI中的ValidateUser方法檢查用戶的合法性，並將用戶ID賦值給ProjectAPI的userID屬性。之後執行Get方法來處理用戶的請求：

func(p *ProjectAPI) Get() {
queryProject :=models.Project{UserID: p.userID}
…
projectList, err :=dao.QueryProject(queryProject)
…
for i := 0; i < len(projectList); i++{
if isProjectAdmin(p.userID,projectList[i].ProjectID) {
projectList[i].Togglable= true
}
}
p.Data["json"] = projectList
p.ServeJSON()
}

Get方法中調用dao包中的QueryProject()方法來獲取項目列表，之後遍歷列表判斷該用戶是否對此項目具有administrator的權限，最終返回項目列表的JSON數據，此次用戶請求處理完畢。

當獲取某個項目的詳細信息時會發送請求http://hostname/registry/detail，該請求同樣會經過Nginx和Router並最終到達其對應的Controller的處理方法如下：

func (idc *ItemDetailController) Get() {
//具體處理邏輯
…
idc.ForwardTo(“page_title_item_details”,“item-detail”)
}

具體的處理邏輯此處忽略。該方法的最後一步調用idc.ForwardTo(“page_title_item_details”,”item-detail”)定位對應的HTML模版文件。模版文件默認的存放目錄爲views，“item-detail”爲模板文件名，因此該語句最終定位到views/item-detail.tpl的文件。經過數據填充最終生成對應的HTML文件並返回。