本發(fā)明涉及docker技術領域，具體涉及docker鏡像倉庫的鏡像同步方法和鏡像同步系統(tǒng)。

背景技術：

docker（docker是一個開源的應用容器引擎，讓開發(fā)者可以打包他們的應用以及依賴包到一個可移植的容器中，然后發(fā)布到任何流行的linux機器上，也可以實現(xiàn)虛擬化）提供的容器技術允許在同一臺主機或虛擬機上運行若干個容器(container)，每個容器就是一個獨立的虛擬環(huán)境或應用。

容器來源于docker鏡像(image)，而鏡像可以由用戶自制或由運行中的容器提交來生成，鏡像生成后，可以推送(push)到鏡像倉庫(registry)中進行保存，也可以從鏡像倉庫拉取(pull)到本地以運行容器。

docker提供了官方鏡像倉庫(dockerhub)，同時允許用戶自行搭建私有鏡像倉庫(privateregistry)。對于大多數(shù)機構和組織，使用私有鏡像倉庫是很有必要的，用以保護倉庫的鏡像內(nèi)容及使用。

鏡像以分層存儲的形式保存于文件系統(tǒng)中，不同的鏡像可能共用某些層(layer)，以節(jié)省存儲空間。對于涉及多區(qū)域用戶訪問的倉庫搭建，當需要統(tǒng)一管理鏡像時，鏡像同步是一項必須的工作，以確保用戶使用的鏡像范圍不局限于某個區(qū)域。

鏡像同步可以由多種方案實現(xiàn)，其中一種是共享存儲，即多個區(qū)域的倉庫（registry）掛載一塊共享的網(wǎng)絡存儲盤，從而可以保證每次有鏡像推送至某區(qū)域的倉庫（registry）時，所有的倉庫（registry）都能立即同步。但有時，多區(qū)域的registry無法共享存儲，且各區(qū)域間的網(wǎng)絡無法互相訪問，即各個區(qū)域之間是隔離的。

在多租戶環(huán)境下使用docker鏡像時，租戶下的用戶通常被限制為只能訪問各個可用區(qū)的公共服務區(qū)內(nèi)部署的鏡像倉庫(registry)。而對于公共鏡像，需要在各個可用區(qū)的鏡像倉庫內(nèi)同步；對于租戶內(nèi)部的私有鏡像，也需要將鏡像同步到各個可用區(qū)。對于用戶來說，其所能看到的各個可用區(qū)內(nèi)的鏡像應該是一致的，而同時各個可用區(qū)的云存儲不能跨區(qū)域共享，不能分發(fā)鏡像事件至其它可用區(qū)，因此不能借助共享存儲的方式來實現(xiàn)同步，而只能使用實時同步。

因此，現(xiàn)有技術還有待于改進和發(fā)展。

技術實現(xiàn)要素：

針對現(xiàn)有技術的上述缺陷，本發(fā)明提供一種docker鏡像倉庫的鏡像同步方法和鏡像同步系統(tǒng)，主要解決現(xiàn)有docker鏡像不能實時同步的問題。

本發(fā)明解決技術問題所采用的技術方案如下：

一種docker鏡像倉庫的鏡像同步方法，所述鏡像同步方法包括如下步驟：

云管區(qū)倉庫收到某一可用區(qū)倉庫推送的鏡像時，通知云管區(qū)控制單元收到鏡像事件；

云管區(qū)控制單元解析鏡像事件，當判斷鏡像事件需要同步時，控制云管區(qū)倉庫將鏡像同步至相應的可用區(qū)倉庫。

所述的docker鏡像倉庫的鏡像同步方法中，所述云管區(qū)倉庫收到可用區(qū)倉庫推送的鏡像事件時，通知云管區(qū)控制單元收到所述鏡像事件的步驟之前還包括：

由某一可用區(qū)控制單元控制該可用區(qū)倉庫向云管區(qū)倉庫推送鏡像。

所述的docker鏡像倉庫的鏡像同步方法中，所述云管區(qū)控制單元解析鏡像事件，當判斷鏡像事件需要同步時，控制云管區(qū)倉庫將鏡像同步至相應的可用區(qū)倉庫的步驟包括：

所述云管區(qū)控制單元解析鏡像事件，并判斷鏡像事件是拉取事件還是推送事件；

若鏡像事件為推送事件，確定該鏡像事件需要同步，并調(diào)用云管區(qū)倉庫的api接口將鏡像同步至相應的可用區(qū)倉庫。

所述的docker鏡像倉庫的鏡像同步方法中，若鏡像事件為推送事件，確定該鏡像事件需要同步，并調(diào)用云管區(qū)倉庫的api接口將鏡像同步至相應的可用區(qū)倉庫的步驟包括：

若鏡像事件為推送事件，確定該鏡像事件需要同步；

解析所述鏡像事件的來源以獲取推送該鏡像的可用區(qū)倉庫；

調(diào)用云管區(qū)倉庫的api接口將鏡像同步至除推送給鏡像的可用區(qū)倉庫之外的其他各可用區(qū)倉庫。

所述的docker鏡像倉庫的鏡像同步方法中，所述云管區(qū)控制單元解析鏡像事件，當判斷鏡像事件需要同步時，控制云管區(qū)倉庫將鏡像同步至相應的可用區(qū)倉庫的步驟之后，還包括：

各可用區(qū)倉庫接收到鏡像時，通知該可用區(qū)控制單元收到所述鏡像事件；

該可用區(qū)控制單元判斷所述鏡像事件是否來源于云管區(qū)，如果是，該可用區(qū)倉庫將不再繼續(xù)分發(fā)該鏡像。

所述的docker鏡像倉庫的鏡像同步方法中，當各可用區(qū)均有多個倉庫時，云管區(qū)控制單元控制云管區(qū)倉庫將鏡像同步至相應的可用區(qū)倉庫的步驟包括：

云管區(qū)控制單元識別鏡像事件的真實ip，判斷該真實ip是否與某個可用區(qū)倉庫的真實ip相匹配，若是則不向該可用區(qū)倉庫推送鏡像。

一種docker鏡像倉庫的鏡像同步系統(tǒng)，所述鏡像同步系統(tǒng)包括：

云管區(qū)倉庫，用于收到某一可用區(qū)倉庫推送的鏡像時，通知云管區(qū)控制單元收到鏡像事件；

云管區(qū)控制單元，用于解析所述鏡像事件，當判斷鏡像事件需要同步時，控制云管區(qū)倉庫將鏡像同步至相應的可用區(qū)倉庫。

所述的docker鏡像倉庫的鏡像同步系統(tǒng)，還包括：

可用區(qū)控制單元，用于控制該可用區(qū)倉庫向云管區(qū)倉庫推送鏡像。

所述的docker鏡像倉庫的鏡像同步系統(tǒng)，還包括：

可用區(qū)倉庫，用于接收到鏡像時，通知該可用區(qū)控制單元收到所述鏡像事件；

所述可用區(qū)控制單元，還用于接判斷所述鏡像事件是否來源于云管區(qū)，如果是，該可用區(qū)倉庫將不再繼續(xù)分發(fā)該鏡像。

所述的docker鏡像倉庫的鏡像同步系統(tǒng)，

所述云管區(qū)控制單元，還用于識別鏡像事件的真實ip，判斷該真實ip是否與某個可用區(qū)倉庫的真實ip相匹配，若是則不向該可用區(qū)倉庫推送鏡像。

本發(fā)明公開了docker鏡像倉庫的鏡像同步方法和鏡像同步系統(tǒng)，其鏡像同步方法先由云管區(qū)倉庫收到某一可用區(qū)倉庫推送的鏡像時，通知云管區(qū)控制單元收到鏡像事件；之后，云管區(qū)控制單元解析鏡像事件，當判斷鏡像事件需要同步時，控制云管區(qū)倉庫將鏡像同步至相應的可用區(qū)倉庫。本發(fā)明通過在云管區(qū)、各可用區(qū)域均設置控制單元和倉庫，通過監(jiān)聽docker鏡像倉庫的事件，來實現(xiàn)云管區(qū)與各可用區(qū)域的鏡像同步，從而解決了docker鏡像實時同步的問題。

附圖說明

圖1為本發(fā)明提供的docker鏡像倉庫的鏡像同步方法的較佳實施例的流程圖。

圖2為本發(fā)明提供的docker鏡像倉庫的鏡像同步方法中步驟s200的較佳實施例的流程圖。

圖3為本發(fā)明提供的docker鏡像倉庫的鏡像同步方法中第一應用實施例的示意圖。

圖4為本發(fā)明提供的docker鏡像倉庫的鏡像同步方法中第二應用實施例的示意圖。

圖5為本發(fā)明提供的docker鏡像倉庫的鏡像同步方法中第三應用實施例的示意圖。

圖6為本發(fā)明docker鏡像倉庫的鏡像同步系統(tǒng)的功能原理框圖。

圖7為本發(fā)明docker鏡像倉庫的鏡像同步系統(tǒng)中云管區(qū)控制單元的功能原理框圖。

具體實施方式

為使本發(fā)明的目的、技術方案及優(yōu)點更加清楚、明確，以下參照附圖并舉實施例對本發(fā)明進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

請參閱圖1，其為本發(fā)明提供的docker鏡像倉庫的鏡像同步方法的較佳實施例的流程圖。如圖1所示，本發(fā)明較佳實施例所述的docker鏡像倉庫的鏡像同步方法以下步驟：

s100、云管區(qū)倉庫收到某一可用區(qū)倉庫推送的鏡像時，通知云管區(qū)控制單元收到鏡像事件。

本實施例中，在云管區(qū)和各可用區(qū)域中均設置了控制單元和倉庫，所述云管區(qū)為一個，可用區(qū)為若干個，用于對各可用區(qū)的鏡像進行管理。

較佳地，在步驟s100之前還包括：由某一可用區(qū)控制單元控制該可用區(qū)倉庫向云管區(qū)倉庫推送鏡像。

具體實施時，由用戶終端向可用區(qū)倉庫推送一鏡像，觸發(fā)該區(qū)倉庫通知該可用區(qū)控制單元接收到鏡像事件，可用區(qū)控制單元解析鏡像事件后，判斷鏡像事件是拉取事件還是推送事件，若為推送事件，則調(diào)用該可用區(qū)區(qū)倉庫的api接口（applicationprogramminginterface，應用程序編程接口）將鏡像同步至云管區(qū)倉庫。

步驟s200、云管區(qū)控制單元解析鏡像事件，當判斷鏡像事件需要同步時，控制云管區(qū)倉庫將鏡像同步至相應的可用區(qū)倉庫。

本實施例中，由云管區(qū)控制單元判斷鏡像事件需要同步時，控制云管區(qū)倉庫將鏡像同步至相應的可用區(qū)倉庫中，實現(xiàn)了各可用區(qū)鏡像與云管區(qū)同步。

請參閱圖2，其為本發(fā)明提供的docker鏡像倉庫的鏡像同步方法中步驟s200的較佳實施例的流程圖。

如圖2所示，所述步驟s200包括：

步驟s201、所述云管區(qū)控制單元解析鏡像事件，并判斷鏡像事件是拉取事件還是推送事件；

步驟s202、若鏡像事件為推送事件，確定該鏡像事件需要同步，并調(diào)用云管區(qū)倉庫的api接口將鏡像同步至相應的可用區(qū)倉庫。當鏡像事件為拉取事件，或者云管區(qū)倉庫中存在該鏡像時，則不進行同步操作。

具體實施時，所述步驟s202包括：

s2021、若鏡像事件為推送事件，確定該鏡像事件需要同步。當鏡像事件為拉取事件，或者云管區(qū)倉庫中存在該鏡像時，則不進行同步操作。

s2022、若鏡像事件為推送事件時，解析所述鏡像事件的來源以獲取推送該鏡像的可用區(qū)倉庫。在云管區(qū)控制單元中，將該源可用區(qū)倉庫的分發(fā)任務剔除，避免出現(xiàn)同步回環(huán)。

s2023、調(diào)用云管區(qū)倉庫的api接口將鏡像同步至除推送給鏡像的可用區(qū)倉庫之外的其他各可用區(qū)倉庫當同步鏡像事件時，不將鏡像分發(fā)給推送該鏡像的可用區(qū)倉庫。

為了更好的理解本發(fā)明的技術方案，此處例舉第一應用實施例對本發(fā)明的docker鏡像倉庫的鏡像同步方法進行詳細說明：

云管區(qū)為集中管理區(qū)，各可用區(qū)可設置在不同的地點，如a可用區(qū)設置在上海、b可用區(qū)設置在北京，c可用區(qū)設置在深圳等。a可用區(qū)、b可用區(qū)和c可用區(qū)之間不能相互通訊，a可用區(qū)、b可用區(qū)和c可用區(qū)只能與云管區(qū)通訊，進行推送或者拉取鏡像操作。

如圖3所示，本發(fā)明的第一應用實施例具體包括：

第一步、由用戶終端向a可用區(qū)倉庫推送鏡像；

第二步、a可用區(qū)倉庫收到鏡像后通知a可用區(qū)控制單元接收到鏡像事件并存儲該鏡像；

第三步、a可用區(qū)控制單元解析鏡像事件后，并控制a可用區(qū)倉庫將鏡像推送至云管區(qū)倉庫；

第四步、云管區(qū)倉庫收到a可用區(qū)倉庫推送的鏡像時，通知云管區(qū)控制單元收到鏡像事件；

第五步、云管區(qū)控制單元解析鏡像事件，當判斷鏡像事件為推送事件時，控制云管區(qū)倉庫將鏡像同步至a可用區(qū)倉庫、b可用區(qū)倉庫和c可用區(qū)倉庫，當判斷鏡像事件為拉取事件時，不處理該鏡像事件。

為避免浪費網(wǎng)絡資源，本發(fā)明還采取了防止回環(huán)和過濾機制，所述步驟s202還包括：若鏡像事件為推送事件時，解析所述鏡像事件的來源；當同步鏡像事件時，不將鏡像分發(fā)給推送該鏡像的可用區(qū)倉庫。

本實施例中，在判斷鏡像事件的來源時，通過識別推送鏡像的可用區(qū)倉庫的ip，從而能準確判斷事件推送來源。

進一步的，在步驟s200之后，本發(fā)明的docker鏡像倉庫的鏡像同步方法還包括：

步驟s300、各可用區(qū)倉庫接收到鏡像時，通知該可用區(qū)控制單元收到所述鏡像事件；

步驟s400、該可用區(qū)控制單元判斷所述鏡像事件是否來源于云管區(qū)，如果是，該可用區(qū)倉庫將不再繼續(xù)分發(fā)該鏡像。

本發(fā)明通過在云管區(qū)和各可用區(qū)均設置防止回環(huán)和過濾機制，防止鏡像推送事件無限回環(huán)，有效節(jié)省了網(wǎng)絡資源。

為了便于更好的理解本發(fā)明的回環(huán)機制，此處例舉第二應用實施例對本發(fā)明的docker鏡像倉庫的鏡像同步方法進行詳細說明：

如圖4所示，本發(fā)明的第二應用實施例具體包括：

第一步、a可用區(qū)倉庫將鏡像推送至云管區(qū)倉庫；

第二步、云管區(qū)倉庫收到a可用區(qū)倉庫推送的鏡像時，通知云管區(qū)控制單元收到鏡像事件；

第三步、云管區(qū)控制單元解析鏡像事件，當判斷鏡像事件為推送事件，并確定該鏡像事件需要同步時，分析出推送事件的來源為a可用區(qū)倉庫，并將a可用區(qū)倉庫的分發(fā)任務剔除；

第四步、云管區(qū)控制單元將分發(fā)任務發(fā)送給云管區(qū)倉庫；

第五步、云管區(qū)倉庫將鏡像分發(fā)給b可用區(qū)倉庫和c可用區(qū)倉庫；

第六步、b可用區(qū)倉庫和c可用區(qū)倉庫接收到鏡像后，通知b可用控制單元和c可用控制單元接收到鏡像事件；

第七步、b可用控制單元和c可用控制單元分析鏡像事件的來源為云管區(qū)，將本次的推送任務刪除，不再進行分發(fā)，避免了回環(huán)（即避免推送鏡像循環(huán)）。

在鏡像同步時，有可能會出現(xiàn)同步失敗的情況（譬如：鏡像同步時，出現(xiàn)網(wǎng)終異常導致鏡像同步失?。瑸榱颂岣哏R像同步的準確率，在本發(fā)明的docker鏡像倉庫的鏡像同步方法中，所述云管區(qū)倉庫定時將所有鏡像推送至各可用區(qū)倉庫。具體實施時，云管區(qū)控制單元控制云管區(qū)倉庫每天凌晨兩點定時向各可用區(qū)推送鏡像。

為了避免鏡像同步重復，在定期同步時，云管區(qū)控制單元調(diào)用源鏡像倉庫的api接口將鏡像推送到相應的可用區(qū)倉庫，并與該可用區(qū)倉庫進行交互檢測可用區(qū)倉庫是否存在所推送的鏡像；當檢測鏡像存在時，中止推送所述鏡像。

在更加復雜的網(wǎng)絡環(huán)境中，一個可用區(qū)內(nèi)設有多個可用區(qū)倉庫，并使負載均衡，各可用區(qū)倉庫對外提供一個vip（veryimportantperson，貴賓）及端口時，則以該可用區(qū)為目標的區(qū)域應將鏡像推送至該vip及端口，且判斷回環(huán)時，應查看事件來源是否為其可用區(qū)倉庫的真實ip及端口。

因此，當各可用區(qū)均有多個倉庫時，云管區(qū)控制單元控制云管區(qū)倉庫將鏡像同步至相應的可用區(qū)倉庫時，具體為：云管區(qū)控制單元識別鏡像事件的真實ip，判斷該真實ip是否與某個可用區(qū)倉庫的真實ip相匹配，若是則將可用區(qū)倉庫的分發(fā)任務剔除，不向該可用區(qū)倉庫推送鏡像。

具體地，當一個區(qū)域有多個倉庫時，為使各倉庫負載均衡，本發(fā)明采用令每個區(qū)域的所有倉庫對外提供一個vip及端口，在其他區(qū)域向該區(qū)域推送鏡像時，通過vip及端口下發(fā)。對于各可用區(qū)，其分發(fā)目標只有云管區(qū)鏡像倉庫vip及端口，在該區(qū)域控制單元接到鏡像推送事件時，根據(jù)鏡像事件來源的真實ip，查詢該ip是否為云管區(qū)鏡像倉庫的真實ip之一，若是則將云管區(qū)鏡像倉庫vip從當次分發(fā)任務中剔除，此時當次分發(fā)任務的目標為空，不再繼續(xù)同步鏡像。

對于云管區(qū)，其分發(fā)目標包含各可用區(qū)鏡像倉庫vip及端口，在云管區(qū)控制單元接到鏡像推送事件時，根據(jù)鏡像事件來源的真實ip，查詢該ip是否為某個可用區(qū)鏡像倉庫的真實ip之一，若是則將該區(qū)域鏡像倉庫的vip從當次分發(fā)任務中剔除，此時當次分發(fā)任務的目標為其他的可用區(qū)鏡像倉庫，不再繼續(xù)對來源區(qū)域向下同步，而同步到其他區(qū)域。負載均衡時，同一個鏡像推送請求只會由多個倉庫中的某一個來處理，而多個倉庫共用了存儲，所以它們的任意一個來處理都是相等的，由于有控制單元控制。

為了便于更好的理解各區(qū)域多倉庫時的回環(huán)機制，此處例舉第三應用實施例對本發(fā)明的docker鏡像倉庫的鏡像同步方法進行詳細說明：

如圖5所示，本發(fā)明的第三應用實施例具體包括：

第一步、c可用區(qū)倉庫1將鏡像推送至云管區(qū)倉庫vip及端口；

第二步、云管區(qū)倉庫vip及端口將誶鏡像推送請求交由云管區(qū)倉庫2進行處理；

第三步、云管區(qū)倉庫2收到推送鏡像后，通知云管區(qū)控制單元；

第四步、云管區(qū)控制單元收到鏡像事件后，分析推送鏡像事件的來源的真實ip為c可用區(qū)倉庫1，并將c可用區(qū)的分發(fā)任務剔除；

第五步、云管區(qū)控制單元控制云管區(qū)倉庫2通過云管區(qū)倉庫vip及端口將鏡像推送送a可用區(qū)倉庫vip及端口和b可用區(qū)倉庫vip及端口。

進一地，在云管區(qū)控制單元中還設置有存儲模塊，用于保存?zhèn)}庫及鏡像的內(nèi)容，避免異常情況導致數(shù)據(jù)丟失。具體可在云管區(qū)控制單元接收到推送事件時，將鏡像的具體信息保存在存儲模塊中。

本發(fā)明實現(xiàn)了公共鏡像在各個可用區(qū)的鏡像倉庫內(nèi)能及時同步；租戶內(nèi)部的私有鏡像也能及時同步到各個可用區(qū)，從而保證在任意可用區(qū)內(nèi)，用戶對于公共鏡像以及租戶下的用戶對于租戶內(nèi)部的私有鏡像無能無差別地訪問。

本發(fā)明還提供了一種docker鏡像倉庫的鏡像同步系統(tǒng)，如圖6所示，所述裝置包括：云管區(qū)倉庫11和云管區(qū)控制單元12，所述云管區(qū)倉庫11與云管區(qū)控制單元12通訊，用于收到某一可用區(qū)倉庫推送的鏡像時，通知云管區(qū)控制單元12收到鏡像事件。所述云管區(qū)控制單元12，用于解析所述鏡像事件，當判斷鏡像事件需要同步時，控制云管區(qū)倉庫11將鏡像同步至相應的可用區(qū)倉庫。具體請參閱上述方法對應的實施例。

本發(fā)明的docker鏡像倉庫的鏡像同步系統(tǒng)還包括可用區(qū)倉庫21和可用區(qū)控制單元22，所述可用區(qū)倉庫21連接可用區(qū)控制單元22。所述可用區(qū)為多個。所述可用區(qū)控制單元，用于控制該可用區(qū)倉庫向云管區(qū)倉庫推送鏡像。

具體實施時，由用戶終端向可用區(qū)倉庫21推送一鏡像，觸發(fā)該區(qū)倉庫21通知該可用區(qū)控制單元22接收到鏡像事件，可用區(qū)控制單元22解析鏡像事件后，判斷鏡像事件是拉取事件還是推送事件，若為推送事件，則調(diào)用該可用區(qū)區(qū)倉庫21的api接口將鏡像推送至云管區(qū)倉庫。

所述可用區(qū)倉庫，用于接收到鏡像時，通知該可用區(qū)控制單元收到所述鏡像事件。所述可用區(qū)控制單元，還用于接判斷所述鏡像事件是否來源于云管區(qū)，如果是，使該可用區(qū)倉庫將不再繼續(xù)分發(fā)該鏡像，從而可防止鏡像回環(huán)。

在判斷鏡像事件的來源時，通過識別推送鏡像的可用區(qū)倉庫的ip，從而能準確判斷事件推送來源。請結合圖5，當各可用區(qū)均有多個倉庫時，所述云管區(qū)控制單元，還用于識別鏡像事件的真實ip，判斷該真實ip是否與某個可用區(qū)倉庫的真實ip相匹配，若是則不向該可用區(qū)倉庫推送鏡像。具體請參閱上述方法對應的實施例。

請參閱圖7，具體實施時，所述云管區(qū)控制單元12包括：解析子單元121和鏡像同步子單元122。

所述解析子單元121，用于解析所述鏡像事件，并判斷鏡像事件是拉取事件還是推送事件。所述鏡像同步子單元122，用于鏡像事件為推送事件，確定該鏡像事件需要同步，并則調(diào)用云管區(qū)倉庫的api接口將鏡像同步至各相應的可用區(qū)倉庫。

所述解析子單元121具體用于當鏡像事件為推送事件，確定該鏡像事件需要同步時，解析所述鏡像事件的來源以獲取推送該鏡像的可用區(qū)倉庫。所述鏡像同步子單元122具體用于調(diào)用云管區(qū)倉庫的api接口將鏡像同步至除推送給鏡像的可用區(qū)倉庫之外的其他各可用區(qū)倉庫。具體請參閱上述方法對應的實施例。

進一步的實施例中，所述云管區(qū)控制單元12，還控制云管區(qū)倉庫定時將所有鏡像推送至各可用區(qū)倉庫，以避免鏡像同步時，由于網(wǎng)絡中斷等原因?qū)е络R像同步失敗時，在不影響業(yè)務的前提下進一步確保鏡像同步的準確率。具體請參閱上述方法對應的實施例。

綜上所述，本發(fā)明通過在云管區(qū)、各可用區(qū)域均設置控制單元和倉庫，通過監(jiān)聽docker鏡像倉庫的事件，來實現(xiàn)云管區(qū)與各可用區(qū)域的鏡像同步，從而解決了docker鏡像實時同步的問題。使租戶內(nèi)部的私有鏡像也能及時同步到各個可用區(qū)，從而保證在任意可用區(qū)內(nèi)，用戶對于公共鏡像以及租戶下的用戶對于租戶內(nèi)部的私有鏡像無能無差別地訪問。

當然，本領域普通技術人員可以理解實現(xiàn)上述實施例方法中的全部或部分流程，是可以通過計算機程序來指令相關硬件（如處理器，控制器等）來完成，所述的程序可存儲于一計算機可讀取的存儲介質(zhì)中，該程序在執(zhí)行時可包括如上述各方法實施例的流程。其中所述的存儲介質(zhì)可為存儲器、磁碟、光盤等。

應當理解的是，本發(fā)明的應用不限于上述的舉例，對本領域普通技術人員來說，可以根據(jù)上述說明加以改進或變換，所有這些改進和變換都應屬于本發(fā)明所附權利要求的保護范圍。