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 鏡像倉庫服務，包括：

接下來，我們深入瞭解一下 Harbor 所提供的核心功能。

首先就是 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、GCR、ECR 以及 quay，未來會根據需求來驗證更多第三方倉庫支持（緩存代理與內容複製共享相同的適配器）。在創建項目時選擇啓用緩存功能則新建項目爲緩存項目，不可推送；以創建的普通項目無法直接轉爲緩存項目。另外，使用緩存鏡像的路徑有特定的模式，docker pull /[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 很重要的特點之一。

Harbor 通過引入開源的 Notary 框架實現了與 DTR 兼容的鏡像製品簽名機制。用戶只要在 Docker 客戶端設置以下環境變量, 就可開啓簽名流程:

$ 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 等形式的掃描。

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

Harbor 也考慮到了在特定情況下，某些鏡像 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 自身也具有很強的擴展能力，可以支持不同場景下的集成需求。這些擴展能力可以總結爲以下幾點：

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

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ERxV3d5xth5mbFCdgeNE5g

猜你喜歡