Go 開源說第七期：Harbor助你玩轉雲原生

本文由「GO開源說」第七期 《Harbor助你玩轉雲原生》直播內容修改整理而成，視頻內容較長，本文內容有所刪減和重構。

雲原生技術的興起爲企業數字化轉型帶來新的可能。做爲雲原生的要素之一，帶來更爲輕量級虛擬化的容器技術具備舉足輕重的推進做用。其實很早以前，容器技術已經有所應用，而Docker的出現和興起完全帶火了容器。其關鍵因素是Docker提供了使用容器的完整工具鏈，使得容器的上手和使用變得很是簡單。工具鏈中的一個關鍵，就是定義了新的軟件打包格式-容器鏡像。鏡像包含了軟件運行所須要的包含基礎OS在內的全部依賴，推送至運行時可直接啓動。從鏡像構建環境到運行環境，鏡像的快速分發成爲硬需求。同時，大量構建以及依賴的鏡像的出現，也給鏡像的維護管理帶來挑戰。鏡像倉庫的出現成爲必然。

圖1 鏡像倉庫

鏡像構建以後能夠推送至倉庫儲存和管理，運行時環境在有應用運行需求時，從倉庫拉取特定的應用鏡像來運行。鏡像倉庫做爲鏡像的分發媒介，能夠實現特定的管理和訪問控制機制。倉庫做爲鏡像傳輸流動的主要媒介，成爲雲原生應用平臺運轉的核心要件。Docker開源了其registry實現,  目前已經成爲CNCF的沙箱項目Distribution。不過，Distribution項目僅僅實現了對鏡像存儲的支持，對企業級的一些管理訴求並沒有法提供支持。

 

爲了實現企業級鏡像倉庫的支持，Harbor項目應運而生。

    

Harbor Registry（又稱Harbor雲原生製品倉庫或Harbor鏡像倉庫）由VMware公司中國研發中心雲原生實驗室原創，並於2016年3月開源。Harbor在Docker Distribution的基礎上增長了企業用戶必需的權限控制、鏡像簽名、安全漏洞掃描和遠程複製等重要功能，還提供了圖形管理界面及面向國內用戶的中文支持，開源後迅速在中國開發者和用戶社區流行，成爲中國雲原生用戶的主流容器鏡像倉庫。

 

2018年7月，VMware捐贈Harbor給CNCF，使Harbor成爲社區共同維護的開源項目，也是首個源自中國的CNCF項目。在加入CNCF以後，Harbor融合到全球的雲原生社區中，衆多的合做夥伴、用戶和開發者都參與了Harbor項目的貢獻，數以千計的用戶在生產系統中部署和使用Harbor，Harbor每月的下載量超過3萬次。2020年6月，Harbor成爲首箇中國原創的CNCF畢業項目。目前Harbor主項目已經在GitHub上已經得到了1萬3千多顆星。Harbor項目目前有來自於全球多家公司的14名維護者，200多名核心提交者，以及50多個貢獻公司。Harbor社區依然在蓬勃發展，歡迎更多的貢獻者加入！

Harbor是爲知足企業安全合規的需求而設計的，旨在提供安全和可信的雲原生製品管理，支持鏡像簽名和內容掃描，確保製品管理的合規性、高效性和互操做性。Harbor的功能主要包括四大類：多用戶的管控（基於角色訪問控制和項目隔離）、鏡像管理策略（存儲配額、製品保留、漏洞掃描、來源簽名、不可變製品、垃圾回收等）、安全與合規（身份認證、掃描和CVE例外規則等）和互操做性（Webhook、內容遠程複製、可插拔掃描器、REST API、機器人帳號等）。

 

Harbor提供了多種途徑來幫助用戶快速搭建Harbor鏡像倉庫服務，包括：

• 離線安裝包：經過docker-compose編排運行。安裝包除了包含相關的安裝腳本外，還包含了全部安裝所須要的Harbor組件鏡像，能夠在離線環境下安裝使用。

• 在線安裝包：與離線安裝包相似，惟一的區別就是不包含harbor組件鏡像，安裝時鏡像須要從網絡上的倉庫服務拉取。

• Helm Chart：

  經過Helm的方式將Harbor部署到目標的Kubernetes集羣中。

  目前僅覆蓋Harbor自身組件的部署安裝,其所依賴的諸如數據庫、Redis緩存以及可能的存儲服務須要用戶本身負責。

• Kubernetes Operator：

  基於Kubernetes Operator框架編排部署，重點關注all-in-one的HA部署模式的支持。

  目前還處於開發中，很快就會發布。

   

接下來，咱們深刻了解一下Har bor 所提供的核心功能。

 

首先就是Harbor的資源隔離與多租戶體系，以下圖所示。

Harbor實現了以項目爲單位的資源邏輯隔離體系，基於項目實現RBAC訪問控制和配額管理。用戶對項目資源的訪問是基於其在此項目中所被指派的角色。目前Harbor提供了多個預約義的角色，訪客、開發者、維護者，項目管理員以及系統管理員，權限從低到高逐級遞進，具體詳情可參見： 角色權限集合 （https://goharbor.io/docs/2.2.0/administration/managing-users/user-permissions-by-role/） 。另外，須要特別提到的是，由於是邏輯隔離，在後端實際存儲中仍是共享空間的，這樣避免鏡像的數據層重複存儲，有效下降存儲空間大小。

 

Harbor也支持多種用戶系統，默認支持內嵌的數據庫用戶系統，同時也支持對接AD/LDAP系統以及經過一致的OIDC機制對接其它用戶系統提供商，社區驗證過的提供商能夠參考  OIDC adapters （https://goharbor.io/docs/2.2.0/install-config/harbor-compatibility-list/） 。同時，考慮到CI/CD場景，也提供了項目層面的機器人帳號，方便CI/CD中的集成使用。

 

在剛發佈不久的Harbor  2.2 版本中，對機器人帳號也作了很大的加強。

提供了新的系統級別的機器人帳號以支持經過一組受權來覆蓋多個項目。同時，支持更多類型的權限來受權不一樣的操做和API調用。另外，相對於以前的jwt令牌方式，新的方式帶來更大的靈活性(即便受權範圍或者過時時間發生變化，密碼依然有效）。更多詳情能夠參考系  統級機器人帳號的設計提議 （https://github.com/goharbor/community/pull/148） 。

 

  鏡像倉庫的一個關鍵功能就是實現鏡像的分發。 Harbor在鏡像分發方面，除了常規的鏡像推送和拉取能力外，還提供了多種有效的機制和方 法供用戶來應對不一樣的場景須要。

 

基於策略的鏡像複製機制，能夠幫助用戶實現將源倉庫中的特定鏡像集合在指定的條件下複製到目標鏡像倉庫中。在複製策略中，除了指定源倉庫或者目標倉庫以外，能夠指定多種過濾器(鏡像庫、tag和標籤）與多種觸發模式（手動，基於時間以及定時）且實現對推送（將鏡像從源倉庫推送至目標倉庫）和拉取（將目標倉庫的鏡像拉取到當前倉庫）兩種模式的支持。首次複製爲全量複製，以後會實現增量複製以提高效率。目前Harbor的複製功能已經支持包含Docker Hub、Quay、GCR、ECR等在內的十多種第三方鏡像倉庫，具體列表可參考 Replicaiton adpaters（https://goharbor.io/docs/2.2.0/install-config/harbor-compatibility-list/）。

 

基於複製功能，可有構建主從或者中心-邊緣的多層分發體系，以實現鏡像內容的高效和穩定的分發。以下圖所示。鏡像推送至中心Harbor倉庫，而後複製到其它地理位置上的邊緣倉庫，容器運行時可從就近的邊緣倉庫拉取。

複製能夠解決非實時的複製能力，對於實時場景，Harbor實現項目級別的緩存機制。在建立項目時，能夠啓用項目的緩存機制。這樣在拉取鏡像時，若是項目中不存在，則由適配器將請求代理到項目所配置的上游倉庫中來響應這次拉取的請求，同時將鏡像緩存到項目中，下次再請求此鏡像時，則可直接響應請求。緩存到項目的鏡像製品與「本地」鏡像製品沒有差別，相關的管理策略能夠應用到緩存的鏡像上，好比配額、掃描等。目前支持的緩存代理的上游倉庫除了其它Harbor以外，還支持Docker  Hub 、G CR 、 ECR 以及quay，將來會根據需求來驗證更多第三方倉庫支持（緩存代理與內容複製共享相同的適配器）。在建立項目時選擇啓用緩存功能則新建項目爲緩存項目，不可推送；以建立的普通項目沒法直接轉爲緩存項目。另外，使用緩存鏡像的路徑有特定的模式， docker   pull   <harbor-host>/[cache_project_name]/<repository_path> （ docker   pull   goharbor.io/my_cache_pro/library/nginx:latest)。

在進行大量部署的時候，對倉庫的鏡像拉取請求會產生井噴，進而形成比較重的負擔。而這其中可能有不少重複的鏡像請求，這樣也就形成更多的沒必要要的資源和流量浪費。P2P網絡能夠加速內容的分發，天然也能夠加速鏡像的分發。由於P2P的特質，內容可來源於其它peer節點，這樣能夠有效地減小對上游倉庫的請求。Harbor是鏡像倉庫,自己不支持P2P協議。可是能夠與其它P2P提供者實現集成，進而利用P2P vendor能力實現鏡像的加速。這就是Harbor的鏡像預熱功能。用戶經過在特定項目中建立特定的預熱策略，使用過濾器（repository和tag）來肯定哪些鏡像知足什麼樣的條件（是否簽名，持有特定標籤或者知足特定的漏洞狀態）須要預熱，在何時（就有事件或者基於定時）觸發預熱，將所選鏡像提早從Harbor倉庫傳輸到特定P2P引擎的緩存中，在有拉取請求時，P2P能夠直接開始工做，不須要從上游倉庫獲取首份鏡像內容。目前已經支持的P2P引擎包括CNCF的Dragonfly和Uber的Kraken。

安全已經成爲雲原生關注的要點之一，同時也是平臺的第一要務。Harbor做爲鏡像製品倉庫，也提供了與鏡像相關聯的多種安全機制，這也是Harbor很重要的特色之一。

 

H arbor經過引入開源的Notary框架實現了與D TR 兼容的鏡像製品簽名機制。用戶只要在 D ocker客戶端設置如下環境變量,就可開啓簽名流程 :

$ export DOCKER_CONTENT_TRUST=1

$ export DOCKER_CONTENT_TRUST_SERVER=https://<harbor主機地址>:4443

以後在拉取使用鏡像時，會對內容進行校驗。

鏡像製品是否被簽名，也能夠設置成爲鏡像安全策略之一，這樣能夠保證只有簽名過的鏡像製品才能夠被拉取。

Harbor對舊式的Helm V2 chart的支持是經過chartmuseum來實現的，其簽名機制保持了和Helm社區一致的形式，即經過GPG key的模式。在打包chart時，添加--sign和--key來生成包含有簽名內容的prov文件，以後經過Harbor的web界面或者helm V2的push 插件隨chart的tgz包一同上傳到Harbor。Harbor會識別文件以展現chart是否被簽過名。以後在使用時，能夠對內容進行校驗。

Harbor支持對鏡像製品進行漏洞掃描。考慮到用戶對掃描引擎有不一樣的偏好或者已經投入了特定的掃描引擎，Harbor經過插件式的方式能夠對接多種不一樣的掃描引擎來實現對其所管理的鏡像製品的漏洞掃描能力。目前已經支持的掃描引擎包括 Clair、Trivy、Aqua CSP、Anchore、Sisdig、小佑DoSec以及探真掃描器等，具體列表能夠參考Scanner adapters。將來會支持更多諸如惡意軟件，非法配置以及BOM等形式的掃描。

H arbor基於上述插件式的掃描機制，可向用戶提供特定鏡像的漏洞報告總彙和漏洞詳情列表，便於用戶及時掌握鏡像的漏洞狀態。另外，基於這些漏洞狀態信息，設置與掃描有關的安全策略，即只容許包含某級別如下的鏡像被拉取，大大提高了運行時端的安全可靠性。

H arbor也考慮到了在特定狀況下，某些鏡像tag具備必定的穩定性要求，不能被誤覆蓋，實現了不可變tag的安全機制。用戶經過設置不可變tag的規則，使得知足這個規則的tag都進入不可變動的狀態。

做爲資源的管理儲存平臺，資源的清理和垃圾回收天然也不能缺席。結合鏡像的管理模型和存儲模型，Harbor提供了tag保留機制和垃圾回收兩種能力。

Tag保留機制基於用戶設置的規則計算出須要保留的鏡像tag，而不在保留列表裏的tag則會被清除。用戶能夠設置最多15條規則，每條規則能夠獨立定義過濾器和諸如「保留最近拉取的#個鏡像」或者「保留最近#天內被拉取的鏡像」的附件條件。這裏須要提到的是，以前提到的不可變鏡像tag是不會被清理的。另外，每次清理或者保留的tag列表會在每次規則執行的文本日誌裏保留。Tag的清理不會釋放存儲資源，可是會釋放配額。

清理後端的無用存儲數據則須要GC垃圾回收機制。Harbor支持在線垃圾回收，用戶可經過Harbor的管理界面來觸發或者設置定時循環觸發。每次GC執行的具體信息會被記錄在執行記錄的文本日誌裏，這些信息包含總共分析了多少數據，釋放了多少數據。在2.1版本以前，GC的運行時阻塞式的，即GC運行時系統處於只讀狀態，不容許任何寫操做進行。2.1以後實現非阻塞式GC模式，GC過程依然支持推送新鏡像到Harbor。

要使用Harbor搭建高可用的鏡像倉庫服務，不管是那種部署模式，基本能夠從基於Harbor的鏡像複製功能或者使用共享服務/存儲兩個角度考慮。具體內容能夠參閱《Harbor權威指南》這本書的相關章節。

 

Harbor自身也具備很強的擴展能力，能夠支持不一樣場景下的集成需求。這些擴展能力能夠總結爲如下幾點：

• 基於Swagger的完善Rest API，很容易構建API客戶端來實現API的集成。

• 支持AD/LDAP/OIDC，能夠實現用戶系統的對接。

• 插件化的漏洞掃描機制，掃描引擎vendor能夠基於掃描器API規範實現與Harbor的集成。

• P2P提供商能夠經過實現特定的接口規範來完成與Harbor的集成。

• 第三方鏡像倉庫能夠經過實現特定的複製適配器接口規範來實現與Harbor的互操做。

• 對於符合OCI規範的製品，能夠經過預先定義的OCI annotation來實現元數據的擴展識別，進而使得Harbor API和web界面支持對特定元數據的識別和渲染。

• Harbor從版本2.2開始開放了相關的系統和業務監控參數，能夠方便的實現特定監控平臺對Harbor的接入和監控，方便平常運維工做。

 

以後的版本，Harbor會重點關注：

•  發佈針對Kubernetes平臺部署的harbor operator

• 支持更多組件的監控參數暴露

• 組建性能工做組來不斷解決Harbor中遇到的性能問題並實現持續改進

• IPV6網絡的支持

• 更強大的安全掃描與審查機制

• 組建多架構工做組以實如今非X86 CPU架構平臺上（ARM、AMD和龍芯）構建運行Harbor服務

• 響應更多其餘來自於用戶和社區的需求

 

Harbor一致致力於構建開放、透明和活躍的社區，歡迎你們積極參與到社區中,共同努力並推進Harbor項目不斷向前發展。你們能夠經過多種途徑聯繫社區和參與進來：

• CNCF workspace下的slack channel：#harbor與#harbor-dev

• 公開郵件組：lists.cncf.io/g/harbor-users 和lists.cncf.io/g/harbor-dev

• Twitter：@project_harbor

• 雙週社區例會：雙週週三晚21：00點 zoom https://zoom.us/j/734959521撥入。會議邀請會發送到slack channel和郵件組。

• Demo環境: demo.goharbor.io, 自助註冊帳戶進入。

下面是Harbor公衆號，歡迎你們關注！

本文分享自微信公衆號 - GoCN（golangchina）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。