實現(xiàn)自動打包的系統(tǒng)及方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及互聯(lián)網(wǎng)技術(shù)領(lǐng)域，具體涉及一種實現(xiàn)自動打包的系統(tǒng)及方法。
【背景技術(shù)】
[0002]LXC(Linux Container)容器是一種內(nèi)核虛擬化技術(shù)，可以提供輕量級的虛擬化，以便隔離進(jìn)程和資源，而且不需要提供指令解釋機制以及全虛擬化的其他復(fù)雜性。相當(dāng)于C++中的命名空間(NameSpace)。容器有效地將由單個操作系統(tǒng)管理的資源劃分到孤立的組中，以更好地在孤立的組之間平衡有沖突的資源使用需求。
[0003]Docker是PaaS提供商dotCloud開源的一個基于LXC的高級容器引擎，源代碼托管在Github上，基于go語言并遵從Apache2.0協(xié)議開源。簡單得來說，Docker是一個由GO語言寫的程序運行的“容器”(Linux containers, LXCs);目前云服務(wù)的基石是操作系統(tǒng)級別的隔離，在同一臺宿主機上虛擬出多個主機。Docker則實現(xiàn)了一種應(yīng)用程序級別的隔離，它改變我們基本的開發(fā)、操作單元，由直接操作虛擬主機(VM)轉(zhuǎn)換到操作程序運行的“容器”上來。
[0004]現(xiàn)有技術(shù)一般采用人工方式手動輸入打包命令docker build來對數(shù)據(jù)進(jìn)行打包，這種方式效率低，占用人力資源，并會由于輸入命令的錯誤而無法實現(xiàn)打包，準(zhǔn)確率低。

【發(fā)明內(nèi)容】

[0005]鑒于上述問題，提出了本發(fā)明以便提供一種克服上述問題或者至少部分地解決上述問題的實現(xiàn)自動打包的系統(tǒng)和相應(yīng)的實現(xiàn)自動打包的方法。
[0006]根據(jù)本發(fā)明的一個方面，提供了一種實現(xiàn)自動打包的系統(tǒng)，包括:中心機以及至少一個打包機；中心機內(nèi)部具有提供任務(wù)下發(fā)接口的第一腳本，至少一個打包機內(nèi)部具有提供打包接口的第二腳本；
[0007]中心機適于:接收任務(wù)下發(fā)接口的調(diào)用請求運行第一腳本，以向至少一個打包機發(fā)送打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)；
[0008]至少一個打包機適于:在接收到打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)后，運行第二腳本以對數(shù)據(jù)進(jìn)行打包。
[0009]根據(jù)本發(fā)明的另一方面，提供了一種實現(xiàn)自動打包的方法，應(yīng)用于包括中心機以及至少一個打包機的系統(tǒng)；中心機內(nèi)部具有提供任務(wù)下發(fā)接口的第一腳本，至少一個打包機內(nèi)部具有提供打包接口的第二腳本；方法包括:
[0010]通過中心機接收任務(wù)下發(fā)接口的調(diào)用請求運行第一腳本，以向至少一個打包機發(fā)送打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)；以及
[0011]至少一個打包機在接收到打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)后，運行第二腳本以對數(shù)據(jù)進(jìn)行打包。
[0012]根據(jù)本發(fā)明提供的方案，中心機在接收任務(wù)下發(fā)接口的調(diào)用請求運行第一腳本，向至少一個打包機發(fā)送打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)；至少一個打包機在接收到打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)后，運行第二腳本以對數(shù)據(jù)進(jìn)行打包，實現(xiàn)了數(shù)據(jù)自動打包，無需通過人工輸入命令進(jìn)行數(shù)據(jù)打包，節(jié)省人力資源，克服了由于人工輸入錯誤而無法進(jìn)行打包的缺陷，且該系統(tǒng)便于操作，提高了打包效率和準(zhǔn)確率。
[0013]上述說明僅是本發(fā)明技術(shù)方案的概述，為了能夠更清楚了解本發(fā)明的技術(shù)手段，而可依照說明書的內(nèi)容予以實施，并且為了讓本發(fā)明的上述和其它目的、特征和優(yōu)點能夠更明顯易懂，以下特舉本發(fā)明的【具體實施方式】。
【附圖說明】
[0014]通過閱讀下文優(yōu)選實施方式的詳細(xì)描述，各種其他的優(yōu)點和益處對于本領(lǐng)域普通技術(shù)人員將變得清楚明了。附圖僅用于示出優(yōu)選實施方式的目的，而并不認(rèn)為是對本發(fā)明的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中:
[0015]圖1示出了根據(jù)本發(fā)明一個實施例的實現(xiàn)自動打包的系統(tǒng)的功能框圖；
[0016]圖2示出了根據(jù)本發(fā)明一個實施例的實現(xiàn)自動打包的方法的流程圖；
[0017]圖3示出了根據(jù)本發(fā)明另一個實施例的實現(xiàn)自動打包的方法的流程圖。
【具體實施方式】
[0018]下面將參照附圖更詳細(xì)地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應(yīng)當(dāng)理解，可以以各種形式實現(xiàn)本公開而不應(yīng)被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，并且能夠?qū)⒈竟_的范圍完整的傳達(dá)給本領(lǐng)域的技術(shù)人員。
[0019]現(xiàn)有的數(shù)據(jù)打包一般是通過人工輸入打包命令來實現(xiàn)，在整個打包過程中需要一一輸入對應(yīng)的命令來完成上述打包任務(wù)。本申請?zhí)峁┝艘环N實現(xiàn)自動打包的系統(tǒng)和方法，其提供了至少一個打包機，并通過檢測打包機的狀態(tài)，將打包任務(wù)首先發(fā)送給空閑狀態(tài)的打包機，分布式處理數(shù)據(jù)打包任務(wù)。
[0020]圖1示出了根據(jù)本發(fā)明一個實施例的實現(xiàn)自動打包的系統(tǒng)的功能框圖。如圖1所示，該系統(tǒng)，包括:中心機100以及至少一個打包機110 ;中心機100內(nèi)部具有提供任務(wù)下發(fā)接口的第一腳本，至少一個打包機110內(nèi)部具有提供打包接口的第二腳本。中心機100與至少一個打包機配合使用對數(shù)據(jù)進(jìn)行打包。
[0021]可選地，該系統(tǒng)還包括:鏡像源120以及至少一個宿主機130。其中，鏡像源120，適于存儲至少一個打包機上傳的鏡像數(shù)據(jù)。至少一個宿主機130，適于在接收到拉取鏡像數(shù)據(jù)的消息后，到鏡像源拉取鏡像數(shù)據(jù)。
[0022]可選地，第一腳本用于實現(xiàn)向至少一個打包機發(fā)送打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)。第二腳本用于對數(shù)據(jù)進(jìn)行打包。
[0023]中心機100適于:接收任務(wù)下發(fā)接口的調(diào)用請求運行第一腳本，以向至少一個打包機發(fā)送打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)；及，接收至少一個打包機發(fā)送的上傳結(jié)果信息，根據(jù)上傳結(jié)果信息向至少一個宿主機發(fā)送拉取鏡像數(shù)據(jù)的消息。
[0024]可選地，任務(wù)下發(fā)接口的調(diào)用請求中包含以下調(diào)用信息的一種或多種:鏡像標(biāo)簽、系統(tǒng)文件的相對路徑和第一配置信息；其中，第一配置信息包括:系統(tǒng)文件的基礎(chǔ)路徑、打包機列表信息和超時時間，更具體地，鏡像標(biāo)簽定義了在打包結(jié)束后，上傳至鏡像源中鏡像數(shù)據(jù)的名稱；系統(tǒng)文件(dockerfile)的相對路徑定義了 dockerfile存儲路徑中的用于確定dockerfile所在的底層目錄的部分路徑，dockerf ile由一條一條的指令組成，其包含創(chuàng)建鏡像所需要的全部指令，基于在dockerfile中的指令來創(chuàng)建鏡像；超時時間定義了打包機接收數(shù)據(jù)打包任務(wù)到將鏡像數(shù)據(jù)自動上傳到鏡像源的時間，超過該時間，則說明上傳失敗。
[0025]打包接口的調(diào)用請求中包含以下調(diào)用信息的一種或多種:鏡像標(biāo)簽、系統(tǒng)文件的相對路徑和第二配置信息；其中，第二配置信息包括:系統(tǒng)文件的基礎(chǔ)路徑、鏡像源地址、鏡像數(shù)據(jù)存儲地址，更具體地，系統(tǒng)文件的基礎(chǔ)路徑定義了 dockerfile存儲路徑中的用于確定dockerfile所在的初始目錄的部分路徑；鏡像源地址定義了鏡像源的地址，該地址用于指示打包機在數(shù)據(jù)打包結(jié)束后，鏡像數(shù)據(jù)上傳的地址；鏡像數(shù)據(jù)存儲地址定義了打包機在數(shù)據(jù)打包結(jié)束后，鏡像數(shù)據(jù)存儲在本地的地址。
[0026]中心機100通過任務(wù)下發(fā)接口接收調(diào)用請求，并根據(jù)該調(diào)用請求中的調(diào)用信息運行第一腳本，并在第一腳本運行過程中向至少一個打包機發(fā)送打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)，其中，數(shù)據(jù)打包任務(wù)存儲于中心機100的消息隊列中，中心機100從消息隊列中選擇數(shù)據(jù)打包任務(wù)發(fā)送給打包機列表信息中記錄的打包機。本實施例中，中心機通過任務(wù)下發(fā)接口接收調(diào)用請求具體代碼實現(xiàn)如下:
[0027]octopus-ctl -t test-1mage/centos -p build/test-1mage/centos/Dockerflie-c config.yml
[0028]具體的參數(shù)含義:
[0029]-t鏡像標(biāo)簽
[0030]-p系統(tǒng)文件的相對路徑
[0031]-C第一配置信息:系統(tǒng)文件的基礎(chǔ)路徑、打包機列表信息和超時時間
[0032]可選地，中心機100進(jìn)一步適于:檢測至少一個打包機的狀態(tài)，將打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)發(fā)送至處于空閑狀態(tài)的打包機。打包機的狀態(tài)包括忙碌狀態(tài)和空閑狀態(tài)，忙碌狀態(tài)說明已為打包機分配了數(shù)據(jù)打包任務(wù)，打包機正在進(jìn)行數(shù)據(jù)打包，空閑狀態(tài)說明未給打包機分配數(shù)據(jù)打包任務(wù)。具體地，在檢測到至少一個打包機處于空閑狀態(tài)，則中心機100將打包接口的調(diào)用請求和從消息隊列中選擇數(shù)據(jù)打包任務(wù)發(fā)送給該處于空閑狀態(tài)的打包機。通過檢測至少一個打包機的狀態(tài)，可以有針對性地向處于空閑狀態(tài)的打包機發(fā)送數(shù)據(jù)打包任務(wù)，克服了為部分打包機分配有多個數(shù)據(jù)打包任務(wù)，而卻未給另一部分打包機分配打包任務(wù)的缺陷，保證最尚效的利用打包機，提尚了打包效率。
[0033]可選地，中心機100進(jìn)一步適于:檢測至少一個打包機是否創(chuàng)建有打包進(jìn)程；若中心機檢測到打包機未創(chuàng)建有打包進(jìn)程，則將打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)發(fā)送至該打包機。其中，進(jìn)程是一個具有一定獨立功能的程序關(guān)于某個數(shù)據(jù)集合的一次運行活動，中心機通過檢測至少一個打包機是否創(chuàng)建有打包進(jìn)程，來判斷是否給打包機分配了數(shù)據(jù)打包任務(wù)，若檢測到打包機創(chuàng)建有打包進(jìn)程則說明已給打包機分配任務(wù)；若檢測到打包機未創(chuàng)建有打包進(jìn)程，則說明未給打包機分配任務(wù)，中心機可以將打包接口的調(diào)用請求和從消息隊列中選擇數(shù)據(jù)打包任務(wù)發(fā)送至該打包機。
[0034]中心機100進(jìn)一步適于:通過檢測至少一個打包機創(chuàng)建的進(jìn)程名稱是否包含關(guān)鍵字來確定至少一個打包機是否創(chuàng)建有打包進(jìn)程；若進(jìn)程名稱不包含關(guān)鍵字，則打包機未創(chuàng)建有打包進(jìn)程，將打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)發(fā)送至該打包機。更具體地，至少一個打包機創(chuàng)建進(jìn)程后，會為該進(jìn)程設(shè)置對應(yīng)的進(jìn)程名稱，通過檢測進(jìn)程名稱中是否包含關(guān)鍵字，例如，“打包”等來確定至少一個打包機是否創(chuàng)建有打包進(jìn)程；若進(jìn)程中包含關(guān)鍵字“打包”，則打包機已創(chuàng)建有打包進(jìn)程；若進(jìn)程中不包含關(guān)鍵字“打包”，則打包機未創(chuàng)建有打包進(jìn)程，將打包接口的調(diào)用請求和數(shù)據(jù)打包任務(wù)發(fā)送至該打包機。
[0035]中心機100在接收至少一個打包機發(fā)送的上傳結(jié)果信息后，根據(jù)上傳結(jié)果信息向至少一個宿主機發(fā)送拉取鏡像數(shù)據(jù)的消息。具體地，若中心機100接收到至少一個打包機發(fā)送的上傳成功信息，則中心機100向至少一