共計 2060 個字符，預計需要花費 6 分鐘才能閱讀完成。

如何理解 Harbor 新版本中遠程鏡像復制功能的設計與實現，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

容器鏡像復制和發布一直缺少良好的工具，是實際開發和運維中的一大痛點。開源 Harbor Registry 提供強大的鏡像復制 / 同步能力，成為眾多用戶喜愛的殺手級功能。

在最近發布的版本中，Harbor 新增了基于策略的 Docker 鏡像復制功能，可在不同的數據中心、不同的運行環境之間同步鏡像，并提供友好的管理界面，大大簡化了實際運維中的鏡像管理工作，已經有用戶部署了遠程鏡像雙向復制的案例。丸趣 TV 小編將對該功能的實現原理做詳細介紹。

Harbor 鏡像復制的管理界面

功能簡介

在功能設計方面，Harbor 仍然以“項目”為中心，通過對項目配置“復制策略”，標明需要復制的項目以及鏡像。管理員在復制策略中指明目標實例，即復制的“目的地”，并對它的地址和連接時使用的用戶名密碼進行設置。當復制策略被激活時，源項目下的所有鏡像，都會被復制到目標實例；此外，當源項目下的鏡像被添加或刪除（push 或 delete), 只要策略還在激活狀態，鏡像的變化都會同步到目標實例上去，如下圖所示：

在較大的容器集群中，往往需要多個 Registry 服務器做負載均衡，可以采用主從發布模式，鏡像只需要發布一次，就可以推送到多個 Registry 實例中。同時還支持雙主復制和層次型的多級鏡像發布，如下圖所示： 

設計與實現

在不同的 Registry 實例之間復制鏡像是十分普遍的需求，過去常見的做法是通過拷貝鏡像數據，比如定期通過 rsync 同步文件系統中鏡像的數據，或者，對于部署在 IaaS 服務上的情況，通過對 IaaS 存儲服務一層進行配置實現對象復制，這些方法往往是根據 registry 使用的存儲而采用不同工具。然而對于 Harbor 來說，我們希望降低這種依賴，并提高靈活性，比如用戶可能有一個開發用的 registry 使用文件系統作為存儲，并希望把鏡像同步到基于 S3 存儲的遠端發布用的 registry 上。考慮到這種情況，我們選擇通過調用 registry 本身的 API 下載并傳輸鏡像，從而做到了與下層存儲無關。

在控制方面，我們引入了一個新的組件，Job Service，用來對鏡像復制任務進行管理。當以項目為單位進行復制時，會以鏡像為單位生成一系列任務（job) 由 Job Service 調度管理，Job Service 在執行任務的過程中將每個任務的狀態更新到數據庫中，以便用戶通過 UI 查看。大體結構如下圖所示：

下面介紹一下 Job Service 的實現，從外部看它也是通過 REST API 接收請求調度并執行任務，面臨的問題主要有兩點，首先，接收到大量復制請求時需要進行限流以免消耗過多 IO 資源；其次，復制策略有可能在任務執行過程中改變，比如失效，這就需要一種機制能從外界對運行中的任務進行干預。

我們通過任務隊列，分發器（dispatcher）和 worker pool 實現了生產者消費者模型，利用 Go 語言內置的 channel, 每個任務會通過 scheduler 放到 channel 里，dispatcher 通過 channel 獲得任務，同時，worker 在工作結束后會被放入另一個 channel, dispatcher 通過這個 channel 與 worker 配對，于是，空閑的 worker 通過 dispatcher 獲得任務 id 并執行任務，這樣可以很方便地通過 worker pool 中 worker 數量來控制并發數：

對于另一個問題，每一個 worker 內部是一個抽象的狀態機（state machine)，通過給不同狀態注冊處理器（handler）完成具體工作，同時，狀態機可以受到干預，可以中途取消（cancel）任務，或在任務執行發生異常時將任務置為錯誤（error）狀態丟棄或交給調度器（scheduler）重試。另外由于狀態機的狀態是可定制的，這樣就很方便擴展和調整。對于一個抽象的任務來說，它的狀態轉移如下圖所示： 

而對于具體遠程同步鏡像的任務來說，Running 狀態會被進一步細分成多個子狀態，如下圖所示：

首先, 從源 Harbor 實例下載相應 tag 的 manifest，分析其所包含的 blob，針對每一個 blob，檢查其在目標實例中是否已經存在，如果不存在，則同步此 blob。最后，檢查 manifest 在目標實例中是否已存在，如果不存在，則上傳 manifest。檢查 blob 的存在性，可以有效減少不必要的網絡流量；而由于 manifest 的上傳有可能會觸發鏡像的同步，所以對 manifest 存在性的檢查，則可以避免當同步的多個 Harbor 形成環路時進入不斷同步的死循環狀態。對同一個鏡像中的每一個 tag 重復以上過程，就可以完成整個鏡像的同步工作。

關于如何理解 Harbor 新版本中遠程鏡像復制功能的設計與實現問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注丸趣 TV 行業資訊頻道了解更多相關知識。