欧美在线观看视频网站,亚洲熟妇色自偷自拍另类,啪啪伊人网,中文字幕第13亚洲另类,中文成人久久久久影院免费观看 ,精品人妻人人做人人爽,亚洲a视频

一種基于分布式存儲的Docker鏡像下載方法與流程

文檔序號:12132511閱讀:543來源:國知局
一種基于分布式存儲的Docker鏡像下載方法與流程

本發(fā)明涉及互聯(lián)網(wǎng)領(lǐng)域中的虛擬化方法,特別是涉及通過分布式存儲加速批量下載Docker鏡像的方法。



背景技術(shù):

Docker是一個開源的應(yīng)用容器引擎,旨在提供一個可以運(yùn)行應(yīng)用程序的解決方案,做為目前最流行的輕量級虛擬化技術(shù),因?yàn)橘Y源利用率高及啟動速度快,一度被認(rèn)為是虛擬機(jī)的替代品。例如,可以在Linux系統(tǒng)上迅速創(chuàng)建一個容器container(輕量級虛擬機(jī)),部署和運(yùn)行應(yīng)用成許,并通過配置文件可以輕松實(shí)現(xiàn)應(yīng)用程序的自動化安裝,Docker可以虛擬出多個容器,容器之間可以互相獨(dú)立。但發(fā)展到現(xiàn)在,Docker技術(shù)并沒有虛擬機(jī)發(fā)成熟,虛擬機(jī)是一項(xiàng)高度發(fā)展、非常成熟的技術(shù),可以運(yùn)行最關(guān)鍵的業(yè)務(wù)工作負(fù)載,而Docker依舊在開發(fā)過程中,網(wǎng)絡(luò)棧、安全性、命名空間隔離以及集群管理等依然有很多領(lǐng)域需要改進(jìn),同時(shí)如何加快Docker鏡像的下載從而提升私有集群中多臺機(jī)器啟動相同容器時(shí)的速度也是亟待解決的問題。

Docker鏡像作為容器運(yùn)行環(huán)境的基石,徹底解放了Docker容器創(chuàng)建的生命力,開發(fā)者可以用一個標(biāo)準(zhǔn)的鏡像構(gòu)建一套容器,容器開發(fā)完成后可以直接使用這個容器部署代碼,鏡像下載過程中需要Docker架構(gòu)中多個組件的協(xié)作。雖然每臺運(yùn)行Docker的機(jī)器上本身都保存著部分鏡像,但Docker還有集中存儲鏡像的地方,Registry就是為集中管理、管理和分發(fā)Docker鏡像而設(shè)計(jì)的項(xiàng)目,目前推薦使用的是Registry的第二個版本,即用golang語言實(shí)現(xiàn)的Distribution項(xiàng)目。Docker公司維護(hù)了一個類似于github的官方的鏡像存儲網(wǎng)站DocHub,所有Docker用戶都可以申請帳號并從DocHub下載需要的鏡像或者上傳鏡像供他人使用。同時(shí),用戶也可以通過在私有集群中部署Distribution來管理該集群中的鏡像,本實(shí)施例中的方法主要是基于布有Distribution的私有集群中的鏡像存儲和下載提速方式。

目前關(guān)于Docker鏡像如何在Distribution中存儲的研究主要關(guān)注的是針對Docker鏡像分層的特點(diǎn),為Distribution開發(fā)可以加快鏡像查找和下載速度的新的存儲系統(tǒng),或者為現(xiàn)有的文件系統(tǒng)開發(fā)驅(qū)動。

(1)為現(xiàn)有存儲系統(tǒng)提供driver

為Docker Distribution提供的官方的后端存儲系統(tǒng)編寫driver,大體推薦選擇的存儲系統(tǒng)有這幾個:Local Filesystem、S3、Swift、glance、Google gcs。Local Filesystem這個可能在鏡像很少的情況下出于簡單性會選擇使用,主要問題顯而易見,擴(kuò)展性、可用性方面都受到很大的約束。Swift是一個Consistent Hash的拓?fù)浣Y(jié)構(gòu),添加機(jī)器需要遷移一部分?jǐn)?shù)據(jù)過來,分布式文件系統(tǒng)中文件的潛移導(dǎo)致帶寬占用會比較大,影響線上服務(wù)。S3解決方案對很多不想自己開發(fā)文件系統(tǒng),但同時(shí)希望鏡像存儲端有不錯的擴(kuò)展性及可用性方面的能力的企業(yè)來說也是一個可行的選擇。

上述方法通過使用分布式存儲系統(tǒng)增加了Distribution存儲Docker鏡像的擴(kuò)展性和可用性,但由于這些通用的存儲系統(tǒng)并非針對于Docker鏡像分層并且每個層次大小差別很大的特點(diǎn)設(shè)計(jì)的,所以對于存儲、檢索和下載Docker鏡像的效率并沒有提高。

(2)設(shè)計(jì)新的Docker鏡像存儲系統(tǒng)

Speedy是京東公司開發(fā)的Docker鏡像存儲系統(tǒng),存儲上將多個小文件合并成一個大文件存儲,減少元數(shù)據(jù)存儲空間開銷和性能開銷,同時(shí)在原生文件系統(tǒng)上通過預(yù)分配空間方式,提供接近裸盤的讀寫性能,但兼具原生文件系統(tǒng)的易用性,針對大文件做優(yōu)化,提供斷點(diǎn)續(xù)傳、失敗重試等功能。

在上述方法中,京東雖然通過針對Docker鏡像的特點(diǎn)編寫了特定的存儲系統(tǒng),并通過使用專用的數(shù)據(jù)庫來存儲元數(shù)據(jù)等方式加快了鏡像查找下載速度,使存儲本身已經(jīng)不是瓶頸。但Distribution所在節(jié)點(diǎn)網(wǎng)卡的性能成為了新的瓶頸,該結(jié)構(gòu)并不能擺脫單點(diǎn)瓶頸問題。

綜上,無論是為現(xiàn)有存儲系統(tǒng)寫驅(qū)動還是針對Docker鏡像編寫新的存儲系統(tǒng),在現(xiàn)有Distribution架構(gòu)下,都不能避免Distribution節(jié)點(diǎn)的網(wǎng)絡(luò)瓶頸問題。



技術(shù)實(shí)現(xiàn)要素:

本發(fā)明針對現(xiàn)有技術(shù)的不足,結(jié)合Distribution和分布式文件系統(tǒng)設(shè)計(jì)新的鏡像分發(fā)架構(gòu),利用分布式文件系統(tǒng)將鏡像分片存儲,Docker節(jié)點(diǎn)(這里的節(jié)點(diǎn)指的是物理計(jì)算機(jī)節(jié)點(diǎn),下文中類似術(shù)語皆指物理節(jié)點(diǎn))向Distribution節(jié)點(diǎn)發(fā)送請求時(shí)只傳送元數(shù)據(jù),真正的數(shù)據(jù)去實(shí)際的分布式存儲節(jié)點(diǎn)中去取,從而真正緩解Distribution節(jié)點(diǎn)的網(wǎng)絡(luò)瓶頸。

為了解決上述技術(shù)問題,本發(fā)明提供一種基于分布式存儲的Docker鏡像下載方法,其步驟如下:

步驟S101:將分布式文件系統(tǒng)掛在Registry節(jié)點(diǎn)存儲鏡像的目錄,并且集群中所有節(jié)點(diǎn)都要創(chuàng)建與Registry節(jié)點(diǎn)存儲鏡像目錄相同的目錄并掛載分布式文件系統(tǒng);

步驟S102:集群中的Docker節(jié)點(diǎn)向Registry節(jié)點(diǎn)請求下載鏡像;

步驟S103:Registry節(jié)點(diǎn)根據(jù)Docker節(jié)點(diǎn)的請求確定鏡像層數(shù)據(jù)在分布式文件系統(tǒng)中的存儲位置,并將獲得的鏡像元數(shù)據(jù)返回給Docker節(jié)點(diǎn);

步驟S104:Docker節(jié)點(diǎn)根據(jù)從Registry節(jié)點(diǎn)接收到的元數(shù)據(jù)確定鏡像數(shù)據(jù)的存儲位置,并直接到存儲節(jié)點(diǎn)提取鏡像數(shù)據(jù)。

步驟S101進(jìn)一步包括:Registry節(jié)點(diǎn)在啟動時(shí)會指定一個yml文件作為參數(shù),在該文件中設(shè)置Registry節(jié)點(diǎn)存儲Docker鏡像的目錄、所用的緩存、提供服務(wù)的端口以及后端存儲的驅(qū)動等內(nèi)容。在與Docker節(jié)點(diǎn)建立連接前,Registry節(jié)點(diǎn)先要進(jìn)行初始化,在初始化的過程中確定要使用的后端存儲,并加載相應(yīng)的驅(qū)動。

步驟S102進(jìn)一步包括:集群中的運(yùn)行Docker的節(jié)點(diǎn)向運(yùn)行Registry的節(jié)點(diǎn)請求下載需要的鏡像,集群中運(yùn)行著Docker的機(jī)器啟動要使用的容器,如果這些要啟動容器的節(jié)點(diǎn)上沒有對應(yīng)的鏡像,Docker節(jié)點(diǎn)根據(jù)Registry所在節(jié)點(diǎn)的IP地址和提供服務(wù)的端口號等參數(shù),向Registry節(jié)點(diǎn)請求下載鏡像,這些請求被發(fā)送至Registry節(jié)點(diǎn)。

步驟S103進(jìn)一步包括:Registry節(jié)點(diǎn)查找是否存在要下載的鏡像,如果不存在則返回?zé)o相應(yīng)鏡像標(biāo)識;若存在則Registry會從分布式文件系統(tǒng)讀取Docker鏡像的manifest并傳遞給Docker節(jié)點(diǎn),其中manifest包含鏡像所含所有層的哈希值。Registry根據(jù)解析manifest得到的鏡像包含的所有層的哈希值及各層之間的依賴關(guān)系,獲取鏡像層的存儲目錄位置,根據(jù)獲取的所述存儲目錄位置讀取出鏡像層文件存儲的目錄、文件名、大小等元數(shù)據(jù),之后將這些元數(shù)據(jù)傳遞給Docker節(jié)點(diǎn)。

進(jìn)一步的,其中所述所有層的哈希值是使用安全散列算法SHA-256對鏡像層數(shù)據(jù)進(jìn)行運(yùn)算,得出的256位長的消息摘要。

步驟S104進(jìn)一步包括:Docker節(jié)點(diǎn)將從Registry節(jié)點(diǎn)接收到的鏡像層的存儲目錄和文件名作為輸入,通過一致性哈希算法計(jì)算出哈希值,確定鏡像層在分布式文件系統(tǒng)中的實(shí)際存儲位置,并通過通用的posix標(biāo)準(zhǔn)接口讀取鏡像數(shù)據(jù),通過哈希校驗(yàn)鏡像數(shù)據(jù)完整性并啟動容器。

進(jìn)一步地,哈希校驗(yàn)具體是:Docker節(jié)點(diǎn)從分布式存儲系統(tǒng)讀取完鏡像層數(shù)據(jù)后,對讀取的鏡像層數(shù)據(jù)用SHA-256算法做運(yùn)算,如果得出的256位的哈希值和manifest中存儲的對應(yīng)的哈希值相等,則說明讀取的數(shù)據(jù)是完整,否則說明讀取數(shù)據(jù)的過程出錯。

采用本發(fā)明可以達(dá)到以下技術(shù)效果:

當(dāng)集群中運(yùn)行有Docker的大量機(jī)器同時(shí)向運(yùn)行有Distribution的節(jié)點(diǎn)請求下載Docker鏡像時(shí),避免了原始架構(gòu)中Distribution節(jié)點(diǎn)容易成為網(wǎng)絡(luò)瓶頸的弊端,將數(shù)據(jù)下載流量均勻分散到分布式存儲系統(tǒng)所處的機(jī)器上,從而加速了鏡像分發(fā)過程。

附圖說明

圖1為本發(fā)明基于分布式存儲的Docker鏡像批量下載方法的流程圖;

圖2為本發(fā)明基于分布式存儲系統(tǒng)Glusterfs為例的分布式存儲的Docker鏡像批量下載方法的簡化架構(gòu)示意圖;

圖3為本發(fā)明基于分布式存儲的Docker鏡像批量下載方法的詳細(xì)操作流程圖;

圖4為本發(fā)明基于分布式存儲的Docker鏡像批量下載技術(shù)的數(shù)據(jù)流圖。

具體實(shí)施方式

為了使本申請中的技術(shù)方案被更好地理解,下面將結(jié)合本申請實(shí)施例中的附圖和具體實(shí)施方式,對本申請進(jìn)行清楚、詳細(xì)的描述。

首先對本發(fā)明涉及的術(shù)語及邏輯關(guān)系定義如下:

Docker是一個開源的應(yīng)用容器引擎,它經(jīng)常被用于和虛擬機(jī)相對比;與虛擬機(jī)啟動鏡像類似,Docker也需要基于具體的鏡像來啟動,Docker將鏡像啟動后就形成一個容器;與虛擬機(jī)鏡像不同,為了減少存儲空間并減少分發(fā)鏡像時(shí)的數(shù)據(jù)下載量,Docker鏡像被設(shè)計(jì)成分層(layer)的,同一個鏡像的layers通過union mount的方式連接成一個完整的鏡像,同時(shí),當(dāng)兩個不同的Docker鏡像含有相同的layer時(shí),只需要存儲一次,節(jié)省了存儲空間;為了便于管理鏡像,Docker設(shè)計(jì)了manifest結(jié)構(gòu),該結(jié)構(gòu)定義了Docker鏡像包含了哪些layer和這些layer之間的依賴關(guān)系;同時(shí),為了統(tǒng)一的存儲、管理和分發(fā)Docker鏡像,Docker公司還牽頭開發(fā)了Registry項(xiàng)目,集群中運(yùn)行Docker的機(jī)器可以向Registry上傳鏡像供他人使用,也可以下載鏡像,目前Registry已經(jīng)出現(xiàn)了使用較廣的第二代版本,即Distribution項(xiàng)目。另外,在本文中節(jié)點(diǎn)指的是Docker、Distribution或者分布式存儲系統(tǒng)所在的物理機(jī)器;集群指的是運(yùn)行著Docker,并且包含運(yùn)行著Distribution的節(jié)點(diǎn)的私有計(jì)算機(jī)集群。本文方案可統(tǒng)一在Registry下實(shí)現(xiàn),而不僅限于Distribution項(xiàng)目。

參見圖1,該圖示出了本申請的基于分布式存儲的Docker鏡像批量下載方法的流程。該實(shí)施例包括:

1、步驟S101,將分布式文件系統(tǒng)掛載在Registry節(jié)點(diǎn)存儲鏡像的目錄,并且集群中所有節(jié)點(diǎn)都要創(chuàng)建與Registry節(jié)點(diǎn)存儲鏡像目錄相同的目錄并掛載分布式文件系統(tǒng)。

更具體地,包括:確定Registry節(jié)點(diǎn)存儲Docker鏡像的目錄,在該運(yùn)行Registry的節(jié)點(diǎn)上將要使用的后端存儲系統(tǒng)掛載到該存儲Docker鏡像的目錄,同時(shí)在集群中的所有節(jié)點(diǎn)上創(chuàng)建與Registry節(jié)點(diǎn)的鏡像存儲目錄相同的目錄,并將使用的分布式文件系統(tǒng)掛載到目錄上。

很多分布式存儲系統(tǒng)的掛載方式已經(jīng)做的非常簡單,比如Glusterfs、Ceph可以用linux下載mount命令直接掛載存儲目錄,此處所說的集群是實(shí)體計(jì)算機(jī)集合,節(jié)點(diǎn)是一臺計(jì)算機(jī)。

2、步驟S102,集群中的運(yùn)行Docker的節(jié)點(diǎn)向運(yùn)行Registry的節(jié)點(diǎn)請求下載需要的鏡像,集群中運(yùn)行著Docker的機(jī)器啟動要使用的容器,如果這些要啟動容器的節(jié)點(diǎn)上沒有對應(yīng)的鏡像,那么Docker節(jié)點(diǎn)會向Registry節(jié)點(diǎn)請求下載鏡像,即會從運(yùn)行Registry程序的節(jié)點(diǎn)下載鏡像。

Docker在通過run命令啟動容器而Docker宿主機(jī)并不含有運(yùn)行該容器對應(yīng)的鏡像或者Docker通過pull命令直接下載鏡像時(shí),如果在集群中已經(jīng)運(yùn)行了Registry,并且Docker運(yùn)行命令run或者pull命令時(shí)添加了Registry所在節(jié)點(diǎn)的IP地址和提供服務(wù)的端口號等參數(shù),這些請求就會被發(fā)送至Registry節(jié)點(diǎn)。

3、步驟S103,Registry節(jié)點(diǎn)根據(jù)Docker節(jié)點(diǎn)的請求中所帶有的具體參數(shù)確定要下載的Docker鏡像數(shù)據(jù)在分布式文件系統(tǒng)中的存儲位置等數(shù)據(jù),并將獲得的數(shù)據(jù)返回給Docker節(jié)點(diǎn)。由于鏡像由許多層構(gòu)成,鏡像數(shù)據(jù)實(shí)際就是鏡像層的數(shù)據(jù)。這里首先說明Registry存儲鏡像層目錄的特點(diǎn),在Registry中,鏡像層存儲位置的前面幾級目錄是固定的,最后一級目錄是以鏡像層為輸入通過安全散列算法SHA-256計(jì)算出的哈希值。

進(jìn)一步地,其中包括將Docker鏡像的manifest傳遞給Registry,manifest是描述整個鏡像組成的一個數(shù)據(jù)結(jié)構(gòu),其中包含鏡像所含所有層的哈希值,這個哈希值是使用安全散列算法SHA-256對鏡像層數(shù)據(jù)進(jìn)行運(yùn)算,得出的256位長的消息摘要。Registry通過解析manifest得到鏡像包含的所有層的哈希值獲取鏡像層的存儲目錄位置。一旦獲取了鏡像層的存儲位置,Registry就可以讀取鏡像層的目錄、文件名、大小等元數(shù)據(jù),并將這些數(shù)據(jù)傳遞給Docker節(jié)點(diǎn)。

Registry解析鏡像的manifest獲取出SHA哈希值。Docker在上傳鏡像時(shí)會上傳鏡像對應(yīng)的manifest,里面已經(jīng)含有了每層SHA哈希值,如果不含有,那么在上傳過程中會運(yùn)行SHA-256算法,計(jì)算出該值并填入manifest,所以在registry只需要從manifest讀取就可以。

因?yàn)樵赗egistry中,為了節(jié)約存儲空間,一個Docker鏡像包含的鏡像層并不集中存儲到一塊兒,各鏡像層分開存儲,其存儲的前面幾級目錄都是確定的,只有最后一級目錄是該層在manifest中對應(yīng)的哈希值。這樣,Registry在解析了manifest并得到各層對應(yīng)的哈希值和依賴關(guān)系后,便可以拼接出鏡像層存儲位置的目錄。在原來的架構(gòu)中,這里會繼續(xù)讀取鏡像層內(nèi)容并傳給Docker節(jié)點(diǎn)。

在原始的架構(gòu)中,Registry在接收到鏡像下載請求時(shí),通過解析manifest得到標(biāo)識鏡像層的哈希值并拼接出鏡像層的具體存儲目錄后,會繼續(xù)去Registry的存儲后端提取鏡像數(shù)據(jù)返回給Docker節(jié)點(diǎn),當(dāng)存儲后端并不是Registry所在節(jié)點(diǎn)的本地文件系統(tǒng)后,則會首先將鏡像數(shù)據(jù)從存儲后端所在的機(jī)器讀取到Registry節(jié)點(diǎn)然后再傳送到請求鏡像的Docker所在節(jié)點(diǎn),即整個鏡像數(shù)據(jù)都要通過Registry節(jié)點(diǎn),Docker接收到鏡像的所有層的內(nèi)容后,可以通過解析的依賴關(guān)系拼接成整個鏡像。這種松耦合的存儲結(jié)構(gòu)有效避免了鏡像層的重復(fù)存儲;而在我們發(fā)明的架構(gòu)中,Registry在解析出鏡像層的存儲位置目錄后,會繼續(xù)根據(jù)獲取的位置信息讀取出鏡像層文件存儲的目錄、文件名、大小等信息,之后將這些鏡像層數(shù)據(jù)的目錄名、文件名、大小等元數(shù)據(jù)傳遞給Docker節(jié)點(diǎn)。

4、步驟S104,Docker節(jié)點(diǎn)根據(jù)從Registry節(jié)點(diǎn)接收到的數(shù)據(jù)得到鏡像數(shù)據(jù)的存儲位置,并直接到分布式存儲節(jié)點(diǎn)提取鏡像數(shù)據(jù):Docker在執(zhí)行run命令運(yùn)行特定鏡像對應(yīng)的容器或者執(zhí)行pull命令直接下載鏡像時(shí),該Docker所在的機(jī)器中不再是直接從Registry所在節(jié)點(diǎn)提取鏡像數(shù)據(jù)了,而是根據(jù)Registry返回的元數(shù)據(jù)信息直接去分布式存儲節(jié)點(diǎn)提取數(shù)據(jù),通過一致性哈希算法計(jì)算出哈希值,確定鏡像層的實(shí)際存儲位置,并通過通用的posix標(biāo)準(zhǔn)接口讀取鏡像數(shù)據(jù),這樣大大緩解了Registry所在節(jié)點(diǎn)的網(wǎng)絡(luò)壓力。

這里所用的一致性哈希算法與上面manifest中存的計(jì)算鏡像層的哈希算法是不同的,計(jì)算鏡像層哈希值用的是安全散列算法SHA-256,是為了用一個固定的256位長度的字符串指代鏡像層,該算法產(chǎn)生的哈希值會根據(jù)輸入的鏡像層內(nèi)容不同而改變,且重復(fù)的概率幾乎為零;而一致性哈希算法,是一種分布式哈希實(shí)現(xiàn)算法,在這里解決的是文件的定位問題。具體的實(shí)現(xiàn)方式是,一致性哈希算法將輸入的文件目錄和文件名,經(jīng)過哈希計(jì)算后散列到一個環(huán)上,之后將運(yùn)行有分布式文件系統(tǒng)的機(jī)器也通過該算法映射到環(huán)上,這樣文件對象和機(jī)器位于同一個哈希空間中,就能快速定位對象位于的機(jī)器了。

接收到數(shù)據(jù)后再通過做哈希校驗(yàn)數(shù)據(jù)完整性。這里哈希校驗(yàn)的目的是為了確保Docker根據(jù)Registry返回的元數(shù)據(jù)而從分布式文件系統(tǒng)讀取的數(shù)據(jù)的完整性,具體校驗(yàn)方法是,前面我們說過manifest中存儲著鏡像包括的所有層的哈希值,這個值是通過以鏡像層數(shù)據(jù)為數(shù)據(jù)通過SHA-256算法計(jì)算出的可以唯一標(biāo)識對應(yīng)鏡像層的256位長的字符串,這里在Docker節(jié)點(diǎn)從分布式存儲系統(tǒng)讀取完鏡像數(shù)據(jù)后,如果這個數(shù)據(jù)是完整的,那么再對這個讀取的鏡像層數(shù)據(jù)用SHA-256算法做運(yùn)算,得出的256位的哈希值應(yīng)該是和manifest中存儲的對應(yīng)的哈希值是相等的。如果不相等,說明讀取數(shù)據(jù)的過程出了錯。

步驟S101中已經(jīng)將分布式文件系統(tǒng)掛載在Registry節(jié)點(diǎn)存儲鏡像的目錄,并且集群中所有Docker節(jié)點(diǎn)都已經(jīng)創(chuàng)建了與Registry節(jié)點(diǎn)存儲鏡像目錄相同的目錄并掛載分布式文件系統(tǒng),根據(jù)分布式文件系統(tǒng)比如Glusterfs、Ceph的原有特性,在Docker節(jié)點(diǎn)上訪問掛載的目錄下的文件其實(shí)和在Registry節(jié)點(diǎn)上訪問掛在目錄下相同文件最后訪問到的其實(shí)是同一個數(shù)據(jù)。另外,Registry節(jié)點(diǎn)在存儲鏡像層數(shù)據(jù)時(shí),是以鏡像層數(shù)據(jù)存儲的目錄和文件名為輸入,通過一致性哈希算法計(jì)算得出這些數(shù)據(jù)在分布式文件系統(tǒng)中的實(shí)際存儲位置的。又因?yàn)?,Docker節(jié)點(diǎn)上在相同目錄同樣掛在了存儲鏡像的文件系統(tǒng),所以在Docker接收到Registry傳遞來的包含鏡像層存儲目錄、文件名、大小等信息時(shí),可以依然以存儲目錄和文件名為輸入再次通過一致性哈希算法計(jì)算得出鏡像在分布式文件系統(tǒng)中的具體存儲位置,從而可以繞過Registry節(jié)點(diǎn)直接到分布式文件系統(tǒng)去讀取數(shù)據(jù)。

Docker的鏡像下載包括集群中的多臺機(jī)器,涉及Registry節(jié)點(diǎn)、Docker節(jié)點(diǎn)和分布式存儲系統(tǒng)所在的節(jié)點(diǎn)。

步驟S101中,集群中節(jié)點(diǎn),即物理機(jī),在分布式存儲節(jié)點(diǎn)上要預(yù)先裝上要用的文件系統(tǒng),其他節(jié)點(diǎn)上裝上該文件系統(tǒng)的客戶端。Registry在啟動時(shí)會指定一個yml文件作為參數(shù),在該文件中設(shè)置Registry存儲Docker鏡像的目錄、所用的緩存、提供服務(wù)的端口以及后端存儲的驅(qū)動等內(nèi)容。這里,不同的后端分布式文件系統(tǒng)需要不同的驅(qū)動,現(xiàn)在也有很多機(jī)構(gòu)為Registry針對不同的存儲系統(tǒng)編寫不同的驅(qū)動。但是,在本發(fā)明中作為Registry后端存儲,并不是簡單地為Registry針對要使用的分布式文件系統(tǒng)寫一個驅(qū)動,而是使該文件系統(tǒng)可以無縫的存儲鏡像。

如圖2示例所示,結(jié)合Docker鏡像下載過程,以分布式文件系統(tǒng)Glusterfs為例,改變從Registry下載鏡像的架構(gòu)實(shí)現(xiàn)Docke與Registry交換元數(shù)據(jù),而從分布式文件系統(tǒng)接收實(shí)際鏡像數(shù)據(jù)。這種實(shí)現(xiàn),對Registry和Docker兩端的源碼都進(jìn)行了更改。

在具體介紹圖2代表的流程之前,首先對該圖中的模塊做簡要說明,該圖中右側(cè)標(biāo)記有Docker的模塊指的是運(yùn)行有Docker程序的物理機(jī)器,其左側(cè)標(biāo)有Docker Registry和Glusterfs Client的模塊指代的是運(yùn)行有Registry程序的機(jī)器,為了實(shí)現(xiàn)發(fā)明中描述的功能,在此機(jī)器上還安裝了分布式文件系統(tǒng)Glusterfs的客戶端,下面三個標(biāo)有Glusterfs Server的模塊指代的是安裝有分布式文件系統(tǒng)的機(jī)器,途中的連線指的數(shù)據(jù)傳輸過程。

在改變架構(gòu)之前所有數(shù)據(jù)都是通過圖2中的虛線所示的通道傳遞的,Docker會首先向Registry發(fā)出下載鏡像的請求,之后Registry會根據(jù)Docker請求的鏡像以及在與Docker交互的過程中得到的要下載的鏡像的manifest,Registry根據(jù)解析manifest得到的鏡像包含的層的哈希值以及層之間的依賴關(guān)系等數(shù)據(jù)等直接定位鏡像數(shù)據(jù)的存儲目錄,這個哈希值是以鏡像層數(shù)據(jù)為輸入,通過SHA-256算法計(jì)算出的可以唯一標(biāo)識對應(yīng)鏡像層的256位長字符串;然后再以鏡像層的存儲目錄和文件名為輸入,通過一致性哈希算法定位鏡像數(shù)據(jù)在分布式文件系統(tǒng)中的具體存儲位置并讀取鏡像數(shù)據(jù),之后經(jīng)過Registry節(jié)點(diǎn)傳遞到請求下載鏡像的Docker節(jié)點(diǎn),可見整個過程都要經(jīng)過Registry節(jié)點(diǎn),從而Registry節(jié)點(diǎn)成為瓶頸。

本發(fā)明改變架構(gòu)之后,只有鏡像的元數(shù)據(jù)以及Registry和Docker間的控制流的交互是通過圖2中的虛線指示的通道傳遞的,而真正的鏡像數(shù)據(jù)的傳輸則是通過圖2中實(shí)線所指的通道實(shí)現(xiàn)的。本發(fā)明中結(jié)合已經(jīng)在Registry節(jié)點(diǎn)、Docker節(jié)點(diǎn)和分布式存儲結(jié)點(diǎn)掛載的目錄更改Docker在下載鏡像時(shí)的代碼和Registry在接收到Docker發(fā)送來的鏡像下載請求時(shí)的處理方式的代碼,Registry中屏蔽了原來接收到Docker發(fā)送請求時(shí)的處理函數(shù),新增了接收到Docker發(fā)送層下載請求時(shí)確定該數(shù)據(jù)存儲目錄以及文件名、文件大小的函數(shù),并通過HTTP發(fā)送給Docker;Docker端新增加了接收到從Registry端接收到數(shù)據(jù)存儲目錄、文件名數(shù)據(jù)時(shí)的處理函數(shù),此時(shí)Docker節(jié)點(diǎn)會以得到的鏡像層存儲目錄和文件名為輸入,通過一致性哈希算法計(jì)算,確定鏡像層在分布式文件系統(tǒng)中的實(shí)際存儲位置,直接去提取。

在與Docker建立連接前,Registry先要進(jìn)行初始化,在初始化的過程中確定要使用的后端存儲,并加載相應(yīng)的驅(qū)動。

步驟S102中,本發(fā)明雖然改變了Registry與Docker交換實(shí)際鏡像的方式,將原始的交換數(shù)據(jù)必須經(jīng)過Registry節(jié)點(diǎn)的架構(gòu)改變?yōu)榱私粨Q實(shí)際鏡像數(shù)據(jù)時(shí)Docker會繞過Registry節(jié)點(diǎn)之間從分布式文件系統(tǒng)所部署的機(jī)器上提取的方式,但是并沒有破壞Docker原本的使用方式,只要做好了本發(fā)明系統(tǒng)所有的準(zhǔn)備工作,集群中的機(jī)器在啟動大量容器時(shí)只需像之前一樣運(yùn)行run命令就可以,Docker會正常通過本發(fā)明中的數(shù)據(jù)傳輸流程下載鏡像并做好hash校驗(yàn)后存儲到本地,并基于通過本發(fā)明系統(tǒng)下載好的鏡像運(yùn)行容器。

步驟S103和S104描述了從Registry接收鏡像下載請求到Docker接收到鏡像數(shù)據(jù)的全過程,流程如圖3所示,具體如下:

Docker節(jié)點(diǎn)通過下載鏡像或者運(yùn)行容器的命令向Registry節(jié)點(diǎn)請求要下載的鏡像;

Registry節(jié)點(diǎn)和Docker節(jié)點(diǎn)間相互認(rèn)證建立安全連接;

Registry節(jié)點(diǎn)接收請求并根據(jù)初始化時(shí)注冊的Handler提供服務(wù),其中Handler包含的是Registry節(jié)點(diǎn)在接收到Docker節(jié)點(diǎn)發(fā)送來的請求時(shí)的處理函數(shù)。本發(fā)明實(shí)現(xiàn)的結(jié)合后端分布式存儲系統(tǒng)從而僅通過Registry傳遞元數(shù)據(jù),具體鏡像數(shù)據(jù)繞過Registry節(jié)點(diǎn),其中就改變了Handler中了部分代碼,并新添加了向Docker返回文件存儲目錄數(shù)據(jù)信息的函數(shù),相應(yīng)的也在Docker的源碼中添加了向分布式文件系統(tǒng)中讀取鏡像數(shù)據(jù)的函數(shù)。本發(fā)明中元數(shù)據(jù)的傳輸并沒有繞過Registry節(jié)點(diǎn),因?yàn)樵獢?shù)據(jù)原本就很小,不會占用太多流量,假如繞過Registry在判斷完整性方面反而會有延遲。所以,本發(fā)明中,Registry會根據(jù)在初始化時(shí)注冊的存儲驅(qū)動以及在步驟S101中掛載的文件系統(tǒng),去查找是否存在要下載的鏡像,如果不存在返回?zé)o相應(yīng)鏡像標(biāo)識,若存在則首先從文件系統(tǒng)中讀取鏡像的manifest到Registry節(jié)點(diǎn),之后返回給Docker節(jié)點(diǎn);

前面已經(jīng)解釋過每個鏡像對應(yīng)的manifest結(jié)構(gòu)包含了該鏡像所包含的所有l(wèi)ayers(鏡像層)的名稱、大小、依賴關(guān)系等數(shù)據(jù)。Docker接收到從Registry返回的manifest后會讀取manifest中包含的鏡像層并與本地存儲的鏡像層做對比,找出本地不存在的層返回給Registry節(jié)點(diǎn);

接下來,按照原來的架構(gòu)Registry會繼續(xù)從后端存儲系統(tǒng)中讀取實(shí)際鏡像數(shù)據(jù),然后經(jīng)過Registry節(jié)點(diǎn)中轉(zhuǎn)最后傳遞給Docker節(jié)點(diǎn);

本發(fā)明中,這次Registry接收到請求后,并不會直接去分布式存儲中讀取鏡像層數(shù)據(jù),而是根據(jù)接收到的層的名稱確定該層對應(yīng)的存儲目錄以及對應(yīng)文件大小等元數(shù)據(jù),之后Registry節(jié)點(diǎn)將這些元數(shù)據(jù)傳遞給Docker節(jié)點(diǎn);

Docker節(jié)點(diǎn)由于在準(zhǔn)備階段也創(chuàng)建了與Registry節(jié)點(diǎn)指定的存儲鏡像的目錄相同的目錄,并也在目錄上與Registry節(jié)點(diǎn)掛載了同樣文件系統(tǒng)并做了相應(yīng)配置,故Docker節(jié)點(diǎn)可以將從Registry節(jié)點(diǎn)接收到的鏡像層的存儲目錄和文件名作為數(shù)據(jù),根據(jù)分布式文件系統(tǒng)使用的通過對鏡像層存儲的目錄以及文件名計(jì)算分布式hash值,確定鏡像層的實(shí)際存儲位置,具體可以得出鏡像存儲位置的原因已經(jīng)在前面有過描述,并通過通用的posix標(biāo)準(zhǔn)接口讀取鏡像層的數(shù)據(jù),即鏡像層數(shù)據(jù)。

具體的數(shù)據(jù)流如圖4所示,這里首先對圖中包括的模塊做簡要解釋,圖中右側(cè)標(biāo)有Docker的模塊指的是運(yùn)行有Docker程序的物理機(jī)器;左側(cè)標(biāo)有Distribution FrontEnd的比較大的模塊指的是運(yùn)行有第二代版本的Registry,即Distribution的物理機(jī)器,其中,Configuration模塊是用來Distribution啟動時(shí)注冊所使用的后端存儲驅(qū)動、服務(wù)端口號等數(shù)據(jù)的,App中做得是將Configuration中讀取到的配置數(shù)據(jù)加載到具體的對象并運(yùn)行對象對外提供服務(wù),Http Server做的是監(jiān)聽Docker連接和請求、并把處理結(jié)果返回給Docker,Router是一個分發(fā)器,根據(jù)接收到的請求的不同分發(fā)到不同的Handler,Handler就是接收到請求后使用的具體處理函數(shù)了;下方標(biāo)有Distribution BackEnd的模塊指代的是安裝有分布式文件系統(tǒng)的物理機(jī)器,因?yàn)槠湟鎯ξ挥贒istribution中的Docker鏡像,這里將其命名為Distribution BackEnd;其通過linux中的mount命令掛載到Distribution節(jié)點(diǎn),即圖中Mount模塊。其中步驟①指的是Docker發(fā)送鏡像下載請求,步驟②是指Registry從后端分布式存儲提取manifest數(shù)據(jù)并返回給Docker,因?yàn)槊總€Docker鏡像都對應(yīng)一個manifest,manifest中記錄了鏡像包含的鏡像層(layer),前面說過layer存儲的前面幾級目錄都是固定的,只有最后一級目錄是通過計(jì)算layer的hash值得到的,而且manifest中記錄了layer的hash值,所以這里根據(jù)拼接起的目錄讀取manifest并不困難,步驟③是指Docker通過接收到的manifest計(jì)算得出本地不存在的鏡像layer并就需要下載的層再次發(fā)送請求到Registry,步驟④指的就是Registry去后端存儲提取實(shí)際鏡像數(shù)據(jù)的元數(shù)據(jù)并傳送給Docker,這里所說的元數(shù)據(jù)主要是指鏡像層的存儲目錄、文件名以及大小等,將這些數(shù)據(jù)傳遞給Docker,讓Docker可以據(jù)此計(jì)算出鏡像層的實(shí)際存儲位置,與上面所述類似,因?yàn)殓R像層的存儲目錄有規(guī)律,所以這部讀取元數(shù)據(jù)并不困難,步驟⑤便是Docker根據(jù)從Registry接收到的鏡像元數(shù)據(jù)信息直接去后端存儲中去讀取實(shí)際鏡像數(shù)據(jù)。

本發(fā)明目的是為了通過用分布式文件系統(tǒng)做為Registry存儲后端并繞過Registry直接傳遞鏡像數(shù)據(jù)到Docker節(jié)點(diǎn),從而減輕Registry節(jié)點(diǎn)的網(wǎng)絡(luò)壓力。所以,如何讓容器鏡像數(shù)據(jù)均勻的分布到存儲節(jié)點(diǎn)從而讓Docker節(jié)點(diǎn)可以同時(shí)從盡可能多的節(jié)點(diǎn)下載數(shù)據(jù)成為關(guān)注點(diǎn)之一。經(jīng)過大量嘗試和實(shí)驗(yàn),本發(fā)明指出分布式文件系統(tǒng)中的分片最能實(shí)現(xiàn)該目的,通過分片的方式可以將一個比較大的layer分成幾乎大小相等的數(shù)據(jù)片,從而均勻的分散到分布式文件系統(tǒng)所處的機(jī)器上,繼而分散了網(wǎng)絡(luò)流量,比如Glusterfs中的stripe卷。在Glusterfs中只需確定存儲系統(tǒng)所使用的機(jī)器,在掛載到鏡像存儲目錄時(shí)加上stripe參數(shù)便指定為了分片的存儲方式,同時(shí)在掛載時(shí)還可以在參數(shù)中指定分片的大小,分片太大或者太小效果都不會太明顯,太大了超過了一些鏡像layer的總大小會使鏡像在文件系統(tǒng)中的分布不均勻,太小了導(dǎo)致元數(shù)據(jù)操作太頻繁,經(jīng)測試3M-4M這個區(qū)間比較合適,在五臺存儲節(jié)點(diǎn)以及由10臺機(jī)器構(gòu)成的Docker集群的基礎(chǔ)上測試鏡像下載速度已經(jīng)提升了3倍以上,隨著集群規(guī)模的增大,這個速度的提升將更加明顯。

Docker節(jié)點(diǎn)從分布式存儲中讀取完數(shù)據(jù)后要做的就是對從各存儲節(jié)點(diǎn)讀取來的數(shù)據(jù)進(jìn)行合并,之前提到過在運(yùn)行Docker的機(jī)器上也掛在了Glusterfs的客戶端,這一步就是Glusterfs客戶端完成的,合并完成后做hash完整性校驗(yàn),在確定了鏡像完整性后就可以在此基礎(chǔ)上啟動容器了。

本發(fā)明不僅僅是對鏡像的下載過程做了優(yōu)化,同時(shí)也改變了鏡像的上傳流程。

Docker節(jié)點(diǎn)在保存對鏡像的更改后,如果想上傳到Registry并分享給集群中其他節(jié)點(diǎn)使用時(shí),像未改動之前一樣,可以直接將要分享的鏡像作為參數(shù)通過docker push命令本上傳到Registry,本發(fā)明未對鏡像處理的命令做任何改動,這也是該實(shí)施例的一個優(yōu)點(diǎn)。

同下載流程相似,在本發(fā)明中,在完整準(zhǔn)備工作并做好初始化后,依舊是僅僅通過Registry傳遞鏡像元數(shù)據(jù),而需要上傳的實(shí)際數(shù)據(jù)則繞過Registry直接寫入到分布式文件系統(tǒng),這是本發(fā)明的另一個實(shí)施例。

Docker鏡像在執(zhí)行上傳時(shí),首先會向Registry發(fā)送請求并發(fā)送要上傳的鏡像層元數(shù)據(jù),但是并不會直接將鏡像數(shù)據(jù)上傳,Registry接收到元數(shù)據(jù)后經(jīng)處理會返回給Docker端一個目錄,由于所有節(jié)點(diǎn)在準(zhǔn)備階段已經(jīng)做好分布式存儲系統(tǒng)的掛載等初始化工作,Docker可以根據(jù)接收到的目錄繞過Registry直接通過通用的posix接口向分布式存儲系統(tǒng)寫數(shù)據(jù)。每上傳一層,Docker都會在鏡像對應(yīng)的manifest中填寫該layer層的元數(shù)據(jù)消息。通過循環(huán)的方式將鏡像各layer的數(shù)據(jù)上傳完后,便完成了整個鏡像manifest的組織,然后將該manifest傳遞給Registry。之后,Registry就可以根據(jù)此來通過hash方法校驗(yàn)寫入到存儲系統(tǒng)中的數(shù)據(jù)的完整性了。上述流程完成后,鏡像便組織到Registry中,集群中其他機(jī)器又可以下載使用該上傳的鏡像了。

通過本發(fā)明方案的處理,可以分散鏡像下載時(shí)流過Registry節(jié)點(diǎn)的數(shù)據(jù)量,避免了Registry成為整個系統(tǒng)的瓶頸,從而提高了分發(fā)鏡像的速度。本發(fā)明已經(jīng)對該方法進(jìn)行了實(shí)現(xiàn)和測試,經(jīng)測試在含有五臺分布式存儲節(jié)點(diǎn)、一臺運(yùn)行Distribution的節(jié)點(diǎn)和十臺運(yùn)行Docker的節(jié)點(diǎn)中,鏡像下載速度提升了將近三倍以上,當(dāng)集群規(guī)模增大時(shí),還會有更大的提升。

最后所應(yīng)說明的是,以上實(shí)施例僅用以說明本發(fā)明的技術(shù)方案而非限制,盡管參照較佳實(shí)施例對本發(fā)明進(jìn)行了詳細(xì)說明,本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解,可以對本發(fā)明的技術(shù)方案進(jìn)行修改或者等同替換,而不脫離本發(fā)明技術(shù)方案的精神和范圍。

當(dāng)前第1頁1 2 3 
網(wǎng)友詢問留言 已有0條留言
  • 還沒有人留言評論。精彩留言會獲得點(diǎn)贊!
1
永善县| 陕西省| 沂源县| 克拉玛依市| 靖江市| 乃东县| 镇宁| 辰溪县| 恭城| 昌吉市| 马山县| 务川| 通州区| 朔州市| 黑龙江省| 金乡县| 科技| 石嘴山市| 崇文区| 永登县| 利川市| 安义县| 东光县| 任丘市| 化州市| 廊坊市| 满洲里市| 应用必备| 青州市| 景宁| 临高县| 万全县| 商丘市| 湘潭市| 隆昌县| 青州市| 仁化县| 玉田县| 乐都县| 章丘市| 双流县|