本發(fā)明涉及云計算技術(shù)領(lǐng)域，具體地說是一種面向docker鏡像倉庫的鏡像垃圾清理系統(tǒng)及方法。
背景技術(shù)：
在云計算容器技術(shù)領(lǐng)域的docker鏡像倉庫中，由于鏡像的存儲是分層存儲，每一個鏡像層只會存儲改動的鏡像和存儲依賴的父鏡像存儲層的元信息，在這種存儲結(jié)構(gòu)下，要執(zhí)行刪除鏡像來清理鏡像倉庫的空間，會涉及到兩種難題：一是刪除依賴鏡像層是要首先判斷該依賴層沒有被其它鏡像層依賴，這需要遍歷依賴層，這樣才能更好的清理鏡像和釋放鏡像倉庫空間；二是刪除時候，涉及分布式加鎖，如果刪除某個鏡像層時，恰恰同時有依賴該鏡像層的鏡像在上傳，則會出現(xiàn)上傳的鏡像后續(xù)不可用的問題。
基于上述問題，本發(fā)明提出了一種面向docker鏡像倉庫的鏡像垃圾清理系統(tǒng)及方法，有效解決上述問題。
技術(shù)實現(xiàn)要素：
本發(fā)明的技術(shù)任務(wù)是針對以上不足之處，提供一種面向docker鏡像倉庫的鏡像垃圾清理系統(tǒng)及方法。
一種面向docker鏡像倉庫的鏡像垃圾清理系統(tǒng)，包括兩個鏡像倉庫及以下模塊：請求代理模塊、消息中心模塊、清理模塊、清理agent，其中，
兩個鏡像倉庫分別為主鏡像倉庫、備用鏡像倉庫，主鏡像倉庫負(fù)責(zé)鏡像的上傳和下載請求，備用鏡像倉庫負(fù)責(zé)存儲清洗后的鏡像；
請求代理模塊負(fù)責(zé)請求和鏡像寫入存儲，并根據(jù)消息中心模塊的標(biāo)識信息，執(zhí)行不同代理請求；
消息中心模塊為請求代理模塊提供標(biāo)識信息，該標(biāo)識信息包括開始清理、清理結(jié)束、主鏡像倉庫地址、備用鏡像倉庫地址，并在清理結(jié)束時向鏡像倉庫上的清理agent推送執(zhí)行清空鏡像倉庫的命令；
清理模塊，根據(jù)消息中心的標(biāo)識執(zhí)行定時任務(wù)，對存儲的請求進(jìn)行取上傳和刪除請求的差集，并把差集對應(yīng)的上傳請求再次重新發(fā)送到當(dāng)前的備用鏡像倉庫，執(zhí)行完成后向消息中心發(fā)送標(biāo)識消息；
清理agent，請求agent在接收到消息中心的推送后，執(zhí)行本模塊的清理工作，完成后，向消息中心發(fā)送清理完成消息。
在請求代理模塊將請求和鏡像寫入存儲時，首先配置請求存儲模塊和鏡像存儲模塊，來分別存儲該請求和鏡像，該請求包括上傳鏡像請求和刪除鏡像請求，請求代理模塊把上傳和刪除鏡像的請求記錄到請求存儲模塊中，把鏡像放到鏡像存儲模塊中。
所述請求代理模塊的工作過程為：
請求代理模塊在消息中心中查看當(dāng)前的系統(tǒng)所處的階段：是鏡像垃圾清理階段還是非鏡像垃圾清理階段，并且獲取當(dāng)前的主鏡像地址和備用鏡像倉庫的地址；
如果是非鏡像垃圾清理階段，則向當(dāng)前的主鏡像倉庫透傳發(fā)送請求；
如果是鏡像垃圾清理階段，則上傳鏡像請求向備用鏡像倉庫上傳；下載鏡像時，先通過備用鏡像倉庫下載，如果沒有，則通過主鏡像倉庫下載。
所述消息中心模塊中，在緩存鏡像上傳、刪除請求時，提供開始清理、清理結(jié)束的標(biāo)識按照不同的邏輯執(zhí)行代理請求，清理模塊定時根據(jù)消息中心的標(biāo)識執(zhí)行清理任務(wù)，并向消息中心寫入執(zhí)行階段的標(biāo)識，消息中心根據(jù)收集到的標(biāo)識，向清理agent發(fā)送清理命令，并根據(jù)獲取到的消息標(biāo)識所處階段及時切換主備倉庫的邏輯角色。
所述消息中心模塊中，接受清理模塊和清理agent發(fā)送的消息，進(jìn)行標(biāo)識階段和邏輯主備用鏡像倉庫及向清理agent推送命令，具體實現(xiàn)步驟為：
步驟一：首先進(jìn)行初始化，消息中心模塊設(shè)置當(dāng)前的階段為非清理階段，設(shè)置當(dāng)前的邏輯主備用鏡像倉庫；
步驟二：當(dāng)接收到清理模塊開始清理鏡像消息請求時，設(shè)置當(dāng)前階段為鏡像清理階段；
步驟三：當(dāng)接收到清理模塊發(fā)送的差集請求重發(fā)結(jié)束的消息時，則向清理agent發(fā)送清理本模塊命令；
步驟四：當(dāng)接收到所有的清理agent的清理完成消息后，改變當(dāng)前的階段為非清理階段，切換主備用鏡像倉庫的邏輯角色。
所述清理模塊定時根據(jù)消息中心模塊的標(biāo)識進(jìn)行計算緩存請求的差集和向備用鏡像倉庫執(zhí)行差集請求，其實現(xiàn)步驟為：
清理模塊定時啟動，并向消息中心模塊不斷詢問上階段的清理流程是否結(jié)束；
當(dāng)詢問到上階段清理流程結(jié)束，則在消息中心模塊中標(biāo)識清理工作開始，并從消息中心模塊中獲取到主鏡像倉庫地址和備用鏡像倉庫地址；
清理模塊向請求存儲模塊取得存儲的鏡像上傳請求和鏡像刪除請求，并計算出上傳請求和刪除請求的差集，并從鏡像存儲中獲取到差集對應(yīng)的上傳鏡像請求對應(yīng)的鏡像；
向備用鏡像倉庫執(zhí)行差集對應(yīng)的上傳鏡像請求，全部執(zhí)行完上傳請求后，向消息中心發(fā)送消息，清理模塊上傳鏡像差集請求結(jié)束。
一種面向docker鏡像倉庫的鏡像垃圾清理方法，基于上述系統(tǒng)，該系統(tǒng)中配置有邏輯上可互相替換的主鏡像倉庫、備用鏡像倉庫，該方法的實現(xiàn)步驟為：
緩存鏡像上傳請求和鏡像刪除請求及對應(yīng)鏡像文件，并在指定時間段內(nèi)取鏡像上傳請求和鏡像刪除請求的差集；
切換主備用鏡像倉庫，通過備用鏡像倉庫執(zhí)行差集上傳鏡像請求，執(zhí)行完畢后，停止主鏡像倉庫并清理該主鏡像倉庫；
最后將備用鏡像倉庫作為主鏡像倉庫，原主鏡像倉庫作為備用鏡像倉庫，重復(fù)上述邏輯，進(jìn)行下一輪的鏡像垃圾清理工作。
所述主鏡像倉庫負(fù)責(zé)鏡像的上傳和下載請求，備用鏡像倉庫負(fù)責(zé)存儲清洗后的鏡像。
在切換主備用鏡像倉庫的步驟中，主鏡像倉庫切換成只讀模式，備用鏡像倉庫切換成可讀寫模式，然后根據(jù)緩存的上傳鏡像請求和刪除鏡像請求差集，向備用鏡像倉庫執(zhí)行差集上傳鏡像請求。
在取得上傳請求和鏡像刪除請求的差集前，啟動請求代理模塊只向備用鏡像倉庫上傳下載請求，下載請求失敗的，重發(fā)請求到主鏡像倉庫；然后向備用鏡像倉庫執(zhí)行差集請求，執(zhí)行完成后，通過請求代理模塊，使其只代理上傳下載請求到備用鏡像倉庫。
本發(fā)明的一種面向docker鏡像倉庫的鏡像垃圾清理系統(tǒng)及方法和現(xiàn)有技術(shù)相比，具有以下有益效果：
本發(fā)明的一種面向docker鏡像倉庫的鏡像垃圾清理系統(tǒng)及方法，填補了docker鏡像倉庫中清理鏡像技術(shù)的空白，可以有效地減小docker鏡像倉庫的存儲壓力，可以使得docker鏡像倉庫有效支持頻繁的上傳刪除鏡像的操作，從而快速的清理鏡像和釋放鏡像空間，實用性強，適用范圍廣泛，具有很好的推廣應(yīng)用價值。
附圖說明
附圖1為本發(fā)明的實現(xiàn)示意圖。
具體實施方式
下面結(jié)合附圖及具體實施例對本發(fā)明作進(jìn)一步說明。
如附圖1所示，一種面向docker鏡像倉庫的鏡像垃圾清理系統(tǒng)，包括兩個鏡像倉庫及以下模塊：請求代理模塊、消息中心模塊、清理模塊、清理agent，其中，
兩個鏡像倉庫分別為主鏡像倉庫、備用鏡像倉庫，主備用鏡像倉庫作為邏輯上互相倒換的倉庫，主鏡像倉庫負(fù)責(zé)鏡像的上傳和下載請求，備用鏡像倉庫負(fù)責(zé)存儲清洗后的鏡像；
請求代理模塊負(fù)責(zé)請求和鏡像寫入存儲，并根據(jù)消息中心模塊的標(biāo)識信息，執(zhí)行不同代理請求；
消息中心模塊為請求代理模塊提供標(biāo)識信息，該標(biāo)識信息包括開始清理、清理結(jié)束、主鏡像倉庫地址、備用鏡像倉庫地址，并在清理結(jié)束時向鏡像倉庫上的清理agent推送執(zhí)行清空鏡像倉庫的命令；
清理模塊，根據(jù)消息中心的標(biāo)識執(zhí)行定時任務(wù)，對存儲的請求進(jìn)行取上傳和刪除請求的差集，并把差集對應(yīng)的上傳請求再次重新發(fā)送到當(dāng)前的備用鏡像倉庫，執(zhí)行完成后向消息中心發(fā)送標(biāo)識消息；
清理agent，請求agent在接收到消息中心的推送后，執(zhí)行本模塊的清理工作，完成后，向消息中心發(fā)送清理完成消息。
在請求代理模塊將請求和鏡像寫入存儲時，首先配置請求存儲模塊和鏡像存儲模塊，來分別存儲該請求和鏡像，該請求包括上傳鏡像請求和刪除鏡像請求，請求代理模塊把上傳和刪除鏡像的請求記錄到請求存儲模塊中，把鏡像放到鏡像存儲模塊中。
所述請求代理模塊的具體工作過程為：
上傳鏡像請求和刪除鏡像請求過來時，請求代理模塊會把上傳和刪除鏡像的請求記錄到請求存儲中，把鏡像放到鏡像存儲中，除刪除鏡像請求外，上傳鏡像和下載鏡像請求透傳到后邊；
接下來請求代理模塊會去消息中心查看當(dāng)前的系統(tǒng)所處的階段，是鏡像垃圾清理階段還是平常階段，該平常階段即非鏡像垃圾清理階段，并且獲取當(dāng)前的主鏡像地址和備用鏡像倉庫的地址；
如果是正常階段，則向當(dāng)前的主鏡像倉庫透傳發(fā)送請求；
如果是鏡像垃圾清理階段，則上傳鏡像請求向備用鏡像倉庫上傳；下載鏡像時先向備用鏡像倉庫下，如果沒有，則向主鏡像倉庫下載。
所述消息中心模塊中，在緩存鏡像上傳、刪除請求時，提供開始清理、清理結(jié)束的標(biāo)識按照不同的邏輯執(zhí)行代理請求，清理模塊定時根據(jù)消息中心的標(biāo)識執(zhí)行清理任務(wù)，并向消息中心寫入執(zhí)行階段的標(biāo)識，消息中心根據(jù)收集到的標(biāo)識，向清理agent發(fā)送清理命令，并根據(jù)獲取到的消息標(biāo)識所處階段及時切換主備倉庫的邏輯角色。
所述消息中心模塊中，接受清理模塊和清理agent發(fā)送的消息，進(jìn)行標(biāo)識階段和邏輯主備用鏡像倉庫及向清理agent推送命令，具體實現(xiàn)步驟為：
步驟一：首先進(jìn)行初始化，消息中心模塊設(shè)置當(dāng)前的階段為非清理階段，設(shè)置當(dāng)前的邏輯主備用鏡像倉庫；
步驟二：當(dāng)接收到清理模塊開始清理鏡像消息請求時，設(shè)置當(dāng)前階段為鏡像清理階段；
步驟三：當(dāng)接收到清理模塊發(fā)送的差集請求重發(fā)結(jié)束的消息時，則向清理agent發(fā)送清理本模塊命令；
步驟四：當(dāng)接收到所有的清理agent的清理完成消息后，改變當(dāng)前的階段為非清理階段，切換主備用鏡像倉庫的邏輯角色。
所述清理模塊定時根據(jù)消息中心模塊的標(biāo)識進(jìn)行計算緩存請求的差集和向備用鏡像倉庫執(zhí)行差集請求，其實現(xiàn)步驟為：
1）清理模塊定時啟動，并向消息中心不斷詢問上階段的清理流程是否結(jié)束；
2）當(dāng)詢問到上階段清理流程結(jié)束，則在消息中心中標(biāo)識清理工作開始，并從消息中心中獲取到當(dāng)年的主鏡像倉庫地址和備用鏡像倉庫地址；
3）清理模塊向請求存儲模塊取得存儲的鏡像上傳請求和鏡像刪除請求，并計算出上傳請求和刪除請求的差集，并從鏡像存儲中獲取到差集對應(yīng)的上傳鏡像請求對應(yīng)的鏡像；
4）向備用鏡像倉庫執(zhí)行差集對應(yīng)的上傳鏡像請求，全部執(zhí)行完上傳請求后，向消息中心發(fā)送消息，清理模塊上傳鏡像差集請求結(jié)束；
5）消息中心接收到上傳鏡像差集請求結(jié)束的消息后，則發(fā)送推送到消息到請求存儲、鏡像存儲模塊、主鏡像倉庫的模塊，命令其開始執(zhí)行本模塊的內(nèi)部清理過程；
6）各個清理agent完成清理本模塊的清理后，向消息中心發(fā)送本模塊清理完成的消息
7）當(dāng)消息中心全部接到模塊清理完成的消息后，在同時更改當(dāng)前系統(tǒng)的所處階段為清理工作完成階段和切換主備用鏡像倉庫的角色。
一種面向docker鏡像倉庫的鏡像垃圾清理方法，基于上述系統(tǒng)，該系統(tǒng)中配置有邏輯上可互相替換的主鏡像倉庫、備用鏡像倉庫，該方法的實現(xiàn)步驟為：
緩存鏡像上傳請求和鏡像刪除請求及對應(yīng)鏡像文件，并在指定時間段內(nèi)取鏡像上傳請求和鏡像刪除請求的差集；
切換主備用鏡像倉庫，通過備用鏡像倉庫執(zhí)行差集上傳鏡像請求，執(zhí)行完畢后，停止主鏡像倉庫并清理該主鏡像倉庫；
最后將備用鏡像倉庫作為主鏡像倉庫，原主鏡像倉庫作為備用鏡像倉庫，重復(fù)上述邏輯，進(jìn)行下一輪的鏡像垃圾清理工作。
本方法使用兩個鏡像倉庫，其一作為主倉庫，其二作為備倉庫，主鏡像倉庫負(fù)責(zé)鏡像的上傳和下載請求，備用鏡像倉庫，負(fù)責(zé)存儲清洗后的鏡像。
緩存鏡像上傳請求和鏡像刪除請求及對應(yīng)鏡像文件，并在指定時間段內(nèi)取鏡像上傳請求和鏡像刪除請求的差集。
在取得上傳請求和鏡像刪除請求的差集前，啟動請求代理只向備用鏡像倉庫上傳下載請求，下載請求失敗的，要重發(fā)請求到主鏡像倉庫。
向備用鏡像倉庫執(zhí)行差集請求，執(zhí)行完成后，轉(zhuǎn)換請求代理開關(guān)，使其只代理上傳下載請求到備用鏡像倉庫。
清空主鏡像倉庫鏡像，互換主備用鏡像倉庫角色，等到指定時間段，再次進(jìn)行上述鏡像清理流程。
在切換主備用鏡像倉庫的步驟中，主鏡像倉庫切換成只讀模式，備用鏡像倉庫切換成可讀寫模式，然后根據(jù)緩存的上傳鏡像請求和刪除鏡像請求差集，向備用鏡像倉庫執(zhí)行差集上傳鏡像請求。
在取得上傳請求和鏡像刪除請求的差集前，啟動請求代理模塊只向備用鏡像倉庫上傳下載請求，下載請求失敗的，重發(fā)請求到主鏡像倉庫；然后向備用鏡像倉庫執(zhí)行差集請求，執(zhí)行完成后，通過請求代理模塊，使其只代理上傳下載請求到備用鏡像倉庫。
通過上面具體實施方式，所述技術(shù)領(lǐng)域的技術(shù)人員可容易的實現(xiàn)本發(fā)明。但是應(yīng)當(dāng)理解，本發(fā)明并不限于上述的具體實施方式。在公開的實施方式的基礎(chǔ)上，所述技術(shù)領(lǐng)域的技術(shù)人員可任意組合不同的技術(shù)特征，從而實現(xiàn)不同的技術(shù)方案。
除說明書所述的技術(shù)特征外，均為本專業(yè)技術(shù)人員的已知技術(shù)。