如何理解Harbor新版本中遠(yuǎn)程鏡像復(fù)制功能的設(shè)計(jì)與實(shí)現(xiàn)

如何理解Harbor新版本中遠(yuǎn)程鏡像復(fù)制功能的設(shè)計(jì)與實(shí)現(xiàn)，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

容器鏡像復(fù)制和發(fā)布一直缺少良好的工具，是實(shí)際開(kāi)發(fā)和運(yùn)維中的一大痛點(diǎn)。開(kāi)源Harbor Registry提供強(qiáng)大的鏡像復(fù)制/同步能力，成為眾多用戶(hù)喜愛(ài)的殺手級(jí)功能。

在最近發(fā)布的版本中，Harbor新增了基于策略的Docker鏡像復(fù)制功能，可在不同的數(shù)據(jù)中心、不同的運(yùn)行環(huán)境之間同步鏡像，并提供友好的管理界面，大大簡(jiǎn)化了實(shí)際運(yùn)維中的鏡像管理工作，已經(jīng)有用戶(hù)部署了遠(yuǎn)程鏡像雙向復(fù)制的案例。小編將對(duì)該功能的實(shí)現(xiàn)原理做詳細(xì)介紹。

Harbor鏡像復(fù)制的管理界面

功能簡(jiǎn)介

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

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

設(shè)計(jì)與實(shí)現(xiàn)

在不同的Registry實(shí)例之間復(fù)制鏡像是十分普遍的需求，過(guò)去常見(jiàn)的做法是通過(guò)拷貝鏡像數(shù)據(jù)，比如定期通過(guò)rsync同步文件系統(tǒng)中鏡像的數(shù)據(jù)，或者，對(duì)于部署在IaaS服務(wù)上的情況，通過(guò)對(duì)IaaS存儲(chǔ)服務(wù)一層進(jìn)行配置實(shí)現(xiàn)對(duì)象復(fù)制，這些方法往往是根據(jù)registry使用的存儲(chǔ)而采用不同工具。然而對(duì)于Harbor來(lái)說(shuō)，我們希望降低這種依賴(lài)，并提高靈活性， 比如用戶(hù)可能有一個(gè)開(kāi)發(fā)用的registry使用文件系統(tǒng)作為存儲(chǔ)，并希望把鏡像同步到基于S3存儲(chǔ)的遠(yuǎn)端發(fā)布用的registry上?？紤]到這種情況，我們選擇通過(guò)調(diào)用registry本身的API下載并傳輸鏡像，從而做到了與下層存儲(chǔ)無(wú)關(guān)。

在控制方面，我們引入了一個(gè)新的組件，Job Service，用來(lái)對(duì)鏡像復(fù)制任務(wù)進(jìn)行管理。當(dāng)以項(xiàng)目為單位進(jìn)行復(fù)制時(shí)，會(huì)以鏡像為單位生成一系列任務(wù)（job)由Job Service 調(diào)度管理，Job Service在執(zhí)行任務(wù)的過(guò)程中將每個(gè)任務(wù)的狀態(tài)更新到數(shù)據(jù)庫(kù)中， 以便用戶(hù)通過(guò)UI查看。大體結(jié)構(gòu)如下圖所示：

下面介紹一下Job Service 的實(shí)現(xiàn)，從外部看它也是通過(guò)REST API接收請(qǐng)求調(diào)度并執(zhí)行任務(wù)，面臨的問(wèn)題主要有兩點(diǎn)，首先，接收到大量復(fù)制請(qǐng)求時(shí)需要進(jìn)行限流以免消耗過(guò)多IO資源；其次，復(fù)制策略有可能在任務(wù)執(zhí)行過(guò)程中改變，比如失效，這就需要一種機(jī)制能從外界對(duì)運(yùn)行中的任務(wù)進(jìn)行干預(yù)。

我們通過(guò)任務(wù)隊(duì)列，分發(fā)器（dispatcher）和worker pool實(shí)現(xiàn)了生產(chǎn)者消費(fèi)者模型，利用Go語(yǔ)言?xún)?nèi)置的channel,每個(gè)任務(wù)會(huì)通過(guò)scheduler放到channel里，dispatcher 通過(guò)channel獲得任務(wù)，同時(shí)，worker在工作結(jié)束后會(huì)被放入另一個(gè)channel, dispatcher 通過(guò)這個(gè)channel與worker配對(duì)，于是，空閑的worker通過(guò)dispatcher獲得任務(wù)id并執(zhí)行任務(wù)，這樣可以很方便地通過(guò)worker pool中 worker數(shù)量來(lái)控制并發(fā)數(shù)：

對(duì)于另一個(gè)問(wèn)題，每一個(gè) worker內(nèi)部是一個(gè)抽象的狀態(tài)機(jī)（state machine)，通過(guò)給不同狀態(tài)注冊(cè)處理器（handler）完成具體工作，同時(shí)，狀態(tài)機(jī)可以受到干預(yù)，可以中途取消（cancel）任務(wù)，或在任務(wù)執(zhí)行發(fā)生異常時(shí)將任務(wù)置為錯(cuò)誤（error）狀態(tài)丟棄或交給調(diào)度器（scheduler）重試。 另外由于狀態(tài)機(jī)的狀態(tài)是可定制的，這樣就很方便擴(kuò)展和調(diào)整。對(duì)于一個(gè)抽象的任務(wù)來(lái)說(shuō)，它的狀態(tài)轉(zhuǎn)移如下圖所示： 

而對(duì)于具體遠(yuǎn)程同步鏡像的任務(wù)來(lái)說(shuō)，Running 狀態(tài)會(huì)被進(jìn)一步細(xì)分成多個(gè)子狀態(tài)，如下圖所示：

首先, 從源Harbor實(shí)例下載相應(yīng)tag的manifest，分析其所包含的blob，針對(duì)每一個(gè)blob，檢查其在目標(biāo)實(shí)例中是否已經(jīng)存在，如果不存在，則同步此blob。最后，檢查manifest在目標(biāo)實(shí)例中是否已存在，如果不存在，則上傳manifest。檢查blob的存在性，可以有效減少不必要的網(wǎng)絡(luò)流量；而由于manifest的上傳有可能會(huì)觸發(fā)鏡像的同步，所以對(duì)manifest存在性的檢查，則可以避免當(dāng)同步的多個(gè)Harbor形成環(huán)路時(shí)進(jìn)入不斷同步的死循環(huán)狀態(tài)。對(duì)同一個(gè)鏡像中的每一個(gè)tag重復(fù)以上過(guò)程，就可以完成整個(gè)鏡像的同步工作。

關(guān)于如何理解Harbor新版本中遠(yuǎn)程鏡像復(fù)制功能的設(shè)計(jì)與實(shí)現(xiàn)問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。