[發明專利]一種容器化部署災備機制的方法和系統

有效

• 申請號: 202010727286.9
• 申請日: 2020-07-24
• 公開（公告）號: CN111984366B
• 公開（公告）日: 2023-01-06
• 發明（設計）人: 張波業;馬豹;亓開元
• 申請（專利權）人: 蘇州浪潮智能科技有限公司
• 主分類號: G06F9/455
• 分類號: G06F9/455
• 代理公司: 濟南誠智商標專利事務所有限公司 37105
• 代理人: 李修杰

本發明提出了一種容器化部署災備機制的方法和系統，該方法包括：確保部署工具進程存在；以及在進程下所有服務容器以及容器對應的API接口正常運行；將部署工具壓縮文件、容器化安裝包、以及服務容器提交的鏡像文件壓縮后暫存在部署節點第一臨時目錄后，然后上傳至存儲系統；將位于存儲系統的所有文件拷貝至部署節點第二臨時目錄，在docker主進程可用、部署工具可用和鏡像文件完整的前提下，對部署節點進行恢復還原。基于該方法，還提出了一種容器化部署災備機制的系統。本發明利用存儲服務后端資源平臺，對部署節點的部署工具、容器化安裝包與容器數據進行遠程災備保護，以防止部署節點容器化主進程崩潰時，能得到及時有效的快速恢復。

技術領域

本發明屬于OpenStack技術領域，特別涉及一種容器化部署災備機制的方法和系統。

背景技術

Openstack是一項開源云平臺軟件技術，提供了一個部署的操作平臺和工具集，是一個為用戶綜合提供虛擬化計算服務、存儲服務和網絡服務的云平臺，并且擁有可靠的云部署方案和良好的擴展性，是云計算時代的操作系統。部署作為當前OpenStack系統中極為重要的一環，將OpenStack的各項服務原子化，每項服務均跑在容器中，便捷快速高效。OpenStack服務容器化，雖然方便，但是各項服務作為docker主進程的子進程，對docker(開源的應用容器引擎)主進程存在著強依賴關系，一旦docker主進程出現崩潰或者無法修復的問題，則云平臺的各項服務均無法進行正常提供服務，從而造成云服務癱瘓及其他災難性結果。鑒于部署節點作為云平臺后端執行容器化部署的起點，其重要性主要體現在對云平臺進行升級、重新部署、修改容器服務配置等操作層面，而且部署節點一般只有一個，雖不易造成混亂，但是也存在著風險，即部署節點一旦發生docker主進程故障，那么升級、修改配置、重新部署等操作則都會受到很嚴重的影響，甚至可能造成無法給云平臺進行升級的嚴重問題，從而無法新增并使用新功能。

目前針對云平臺數據層面的備份方案已經很多，比如虛擬機備份、云硬盤數據備份等等方面，但是針對云平臺部署節點的災備保護缺十分稀少。

發明內容

為了解決上述技術問題，本發明提出一種容器化部署災備機制的方法和系統，利用存儲服務后端資源平臺，對部署節點的部署工具、docker安裝包與容器數據進行遠程直接災備保護，以防止部署節點docker主進程崩潰時，能得到及時有效的快速恢復。

為實現上述目的，本發明采用以下技術方案：

一種容器化部署災備機制的方法，包括以下步驟：

S1：確保部署工具進程存在；以及在所述進程下所有服務容器以及所述服務容器所對應的API接口正常運行；

S2：將部署工具壓縮文件、docker安裝包、以及所述服務容器提交的鏡像文件壓縮后暫存在部署節點第一臨時目錄后，然后上傳至存儲系統；

S3：將位于存儲系統的部署工具壓縮文件、docker安裝包、以及所述服務容器提交的鏡像文件拷貝至部署節點第二臨時目錄，在docker主進程可用、部署工具可用和所述鏡像文件完整的前提下，對部署節點進行恢復還原。

進一步的，所述步驟S1包括：

S11：查看部署工具進程是否存在；

S12：在所述部署工具進程存在的前提下，循環檢測所有服務容器，如果檢測到服務容器異常，則退出；直至所有服務容器正常則循環檢測結束；

S13：在所有服務容器正常的前提下，循環檢測所述所有服務容器對應的API功能接口，如果檢測到API功能接口異常，則退出，直至所有API功能接口正常則循環檢測結束，并對所述API功能接口進行封裝。

進一步的，所述步驟S2包括：

S21：將部署工具壓縮文件和docker安裝包保存至部署節點第一臨時目錄；