前言

前一篇文章我們介紹了 Harbor Proxy cache 功能，今天則是要介紹一個與 proxy 類似但非常方便的 image 傳輸功能 ：Replication (複製管理) 服務，可以讓使用者透過圖形化介面，以 手動/自動 方式 推送/拉取 遠端 Image，對於 DevOps CI/CD 流程設計與 Image Registry 維運有相當大的幫助。 本篇文章將簡單介紹 Replication Mode，如有任何錯誤或建議，請各位前輩不吝提出。




前置作業

理所當然，在開始使用 Replication 功能之前，我們需要先建立 Image Registry 基本資料。你可以在左邊選單找到 Registry 管理，點選新增按鈕新增另一座儲存庫資訊。




選擇你的 Image Registry 提供者、輸入名稱、URL與基本驗證資訊。建立完成後，後續即可在 Replication 功能中使用。




Replication 介紹

Replication 功能可以分成 從本地 Harbor 推送 (Push) 至其他 Image Registry 與 從遠端 Image Registry 拉取(Pull) 至本地 Harbor 兩種功能。你能從左邊選單點選資料複製管理後，點選新複製規則開始建立 Replication 功能。



如下圖所示，無論在拉取或推送功能中，使用者必須依序輸入名稱、選擇來源(拉取模式)或目的(推送模式)、Image 名稱、Tag 名稱、對應的命名空間、觸發方式與是否複寫。

注意：推送模式可以設定手動、排程與事件驅動觸發；拉取模式只能設定手動與排程觸發。事件驅動觸發為使用者推送 image 至 Harbor 時觸發，進行更進一步的推送行為。 




我們簡單設定一個事件驅動推送，當有 image 被推送至 Harbor 內 library project 後，即觸發此複製規則，將 image 推送至 dockerhub。



使用者推送 image 後



點選觸發規則，即在下方顯示資料複製紀錄。雖然是事件驅動，但你仍可以透過上方複製按鈕進行手動觸發。



最後，使用者可以在 docker hub 上看到已經推送的 image。





Proxy Cache 與 Replication 比較

經過這兩篇文章介紹，使用者會好奇 Proxy Cache 與 Replication 功能類似，應該在什麼時間點使用呢？ 基本上，除了功能需求 (如排程推送，使用者需要推送 image 至 Project) 一定要選擇 Replication 外，個人會比較推薦在開發過程中，如拉取外部 image 或 base image 時使用 Proxy Cache，多數 CI/CD 流程中使用 Replication。

舉一個簡單子例子：當下週需要 Deploy 至 Prod 時，應該優先先將 Image 推送至 Prod 環境儲存庫，而非部署時透過 proxy cache 或 Pull mode 從非 Prod 環境儲存庫拉取 Image。一來在初次大量部署時仍然影響主要 Harbor 效能，二來在正式部署階段不會因為網路或 Image 掃描問題無法順利部署。