一種容器創建方法和裝置與流程

本公開涉及網絡技術領域，特別涉及一種容器創建方法和裝置。

背景技術：

容器技術是一種操作系統層虛擬化技術，可以將應用軟件系統打包成一個軟件容器，內含應用本身的代碼及其所需要的操作系統核心和庫，通過命名空間技術和硬件資源隔離技術創造出應用獨立的沙箱運行環境。目前，隨著人工智能和圖像處理業務的發展和需求擴大，容器技術也逐步應用于企業高性能計算領域方面的工作。例如，在高性能計算領域，容器中運行的應用有時需要使用某個物理設備，那么為了使得能夠使用該物理設備，創建的容器中需要包括該物理設備的信息，比如，可以是設備的驅動，否則容器就無法使用該設備。

現有技術的其中一種方式，可以將設備的驅動直接安裝在容器中，每個容器中都要安裝該驅動，但是這種方式在驅動版本升級時，所有的容器和鏡像都要更新，而且還需要獲取更新時所需要的設備信息，操作非常繁瑣，而且還會對容器中的業務運行造成影響。

技術實現要素：

有鑒于此，本公開提供一種容器創建方法和裝置，以使得容器對設備的使用實現更加靈活和方便，并減小設備更新對容器業務的影響。

具體地，本公開是通過如下技術方案實現的：

第一方面，提供一種容器創建方法，所述方法應用于攜帶目標設備的容器的創建，所述方法包括：

接收用于創建容器的容器引擎發送的插件觸發請求；

根據所述觸發請求，獲取所述目標設備的設備信息和驅動；

將所述設備信息和驅動返回給所述容器引擎，以使得所述容器引擎創建攜帶所述目標設備的容器。

第二方面，提供一種容器創建方法，所述方法應用于攜帶目標設備的容器的創建，所述方法包括：

向容器插件發送插件觸發請求，所述插件觸發請求用于觸發所述容器插件獲取所述目標設備的設備信息和驅動；

接收所述容器插件返回的所述設備信息和驅動；

使用所述設備信息和驅動，創建攜帶所述目標設備的容器。

第三方面，提供一種容器創建裝置，所述裝置應用于攜帶目標設備的容器的創建，所述裝置包括：

觸發接收模塊，用于接收用于創建容器的容器引擎發送的插件觸發請求；

信息獲取模塊，用于根據所述觸發請求，獲取目標設備的設備信息和驅動；

信息反饋模塊，用于將所述設備信息和驅動返回給所述容器引擎，以使得所述容器引擎創建攜帶所述目標設備的容器。

第四方面，提供一種容器創建裝置，所述裝置應用于攜帶目標設備的容器的創建，所述裝置包括：

請求發送模塊，用于向容器插件發送插件觸發請求，所述插件觸發請求用于觸發所述容器插件獲取所述目標設備的設備信息和驅動；

信息接收模塊，用于接收所述容器插件返回的所述設備信息和驅動；

容器創建模塊，用于使用所述設備信息和驅動，創建攜帶目標設備的容器。

第五方面，提供一種計算機可讀存儲介質，所述介質上存儲有計算機指令，該指令被處理器執行時實現以下步驟：

接收用于創建容器的容器引擎發送的插件觸發請求；

根據所述觸發請求，獲取所述目標設備的設備信息和驅動；

將所述設備信息和驅動返回給所述容器引擎，以使得所述容器引擎創建攜帶所述目標設備的容器。

第六方面，提供一種處理設備，所述處理設備中安裝有目標設備，所述處理設備包括存儲器、處理器，以及存儲在存儲器上并可在處理器上運行的計算機指令，所述計算機指令包括：用于實現容器插件的插件指令、以及用于實現容器引擎的引擎指令；

所述處理器通過執行所述插件指令，用于實現如下步驟：接收用于創建容器的容器引擎發送的插件觸發請求；根據所述觸發請求，獲取所述目標設備的設備信息和驅動；將所述設備信息和驅動返回給所述容器引擎；

所述處理器通過執行所述引擎指令，用于實現如下步驟：向容器插件發送插件觸發請求，所述插件觸發請求用于觸發所述容器插件獲取所述目標設備的設備信息和驅動；接收所述容器插件返回的設備信息和驅動；使用所述設備信息和驅動，創建攜帶所述目標設備的容器。

本公開的容器創建方法和裝置，當容器引擎創建容器時，可以自動觸發本公開的容器插件代為收集目標設備的設備信息和驅動，這樣使得對于容器創建時所需信息的獲取更為快速和方便，并且，插件化的方式對容器中的業務不會產生影響。

附圖說明

圖1是本公開實施例提供的一個容器的應用場景；

圖2是本公開實施例提供的一個容器創建流程圖；

圖3是本公開實施例提供的一個容器插件的結構示意圖；

圖4是本公開實施例提供的容器插件第一階段的工作流程圖；

圖5是本公開實施例提供的容器插件第二階段的工作流程圖；

圖6是本公開實施例提供的容器插件第三階段的工作流程圖；

圖7是本公開實施例提供的驅動設備查詢器的結構示意圖；

圖8是本公開實施例提供的一種容器創建裝置的結構示意圖；

圖9是本公開實施例提供的一種容器創建裝置的結構示意圖；

圖10是本公開實施例提供的一種容器創建裝置的結構示意圖。

具體實施方式

利用容器(container)技術可以為應用程序創造出一個獨立的沙箱運行環境，并不是像虛擬機那樣提供一套完整的操作系統，例如，傳統虛擬機方式運行十個不同的應用就要起十個虛擬機，而容器技術只需要啟動十個隔離的應用即可，這十個應用分別位于不同的容器中。容器的啟動和運行效率較高，而且對系統資源的利用率很高，容器除了運行其中的應用程序外，基本不消耗額外的系統資源，一臺主機上可以同時運行數量很多的容器。正因為上述優點，容器技術逐步應用于各個方面的工作。

圖1示例了一個容器的應用場景，如圖1所示，處理設備11例如可以是一個電腦、服務器等物理機器，或者也可以是一個運行在物理機器上的虛擬機，如下的描述中以物理機器為例。在處理設備11中可以安裝有至少一個硬件設備，在一個例子中，這些硬件設備可以是infiniband設備，infiniband是一種適用于高性能計算領域的計算機網絡通信標準，具有高吞吐、低延遲的傳輸特性，infiniband設備可以包括infiniband交換機和網絡互聯設備等。使用infiniband設備需要攜帶該設備的驅動，如圖1所示，處理設備11中包括物理機infiniband設備12(即安裝在物理機器形式的處理設備上的infiniband，以區分后續描述中出現的容器infiniband)和物理機infiniband驅動13(同理，以區分后續出現的容器驅動)。本例子中，可以將上述的infiniband設備稱為目標設備，此外，如下描述中以infiniband設備為例，但在其他的應用場景中也可以是其他硬件設備。

請繼續參見圖1，假設在該處理設備上創建并運行一個容器14，該容器14中的應用程序需要使用infiniband設備，以提高網絡吞吐量和網絡通信效率，那么容器14可以是一個“攜帶infiniband設備的容器(圖1示意為infiniband容器)”，即需要將infiniband設備掛載在容器14中，容器14還需要包括該infiniband設備的驅動，這樣才能夠正常使用infiniband設備。如圖1所示，容器14中包括容器infiniband設備和驅動，以通過這些共享實際的物理設備。

本公開的容器創建方法，即用于描述如何創建上述的容器14，并且使得該容器14中攜帶處理設備11中的infiniband設備及其驅動。如圖1所示，可以由容器引擎15負責創建容器，在一個例子中，例如，該容器引擎15可以是docker，docker是一個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中，然后發布到任何流行的linux機器上，以期實現構建一次，到處運行，即“buildonce，runanywhere”，docker可以使得應用程序部署在軟件容器下的工作自動化進行。當然，在其他的應用例子中，也可以使用其他的容器引擎，不限制于docker，本公開的后續例子中以docker為例進行描述。

以docker為例，docker可以提供一種擴展機制即docker插件，例如，docker可以支持volume插件。插件是一個獨立的進程，docker插件可以與docker運行在同一臺主機上，由docker進程進行插件觸發。本公開提供了一種插件，如圖1所示的容器插件16，由該容器插件16負責為容器的創建收集所需的infiniband設備信息和驅動，并返回給容器引擎15，以供容器引擎15創建容器。

圖2示例了本公開的容器創建流程，可以包括：

在步驟201中，容器引擎接收容器創建請求，所述容器創建請求用于請求創建攜帶目標設備的容器。

例如，如圖1所示，用戶調度程序可以向docker發送容器創建請求，調度docker進程創建一個攜帶infiniband設備的容器。

在步驟202中，容器引擎向容器插件發送插件觸發請求。

例如，docker進程接收到容器創建請求后，開始進入創建容器的流程。本步驟中，可以通過docker進程的volumedriver觸發本公開中的容器插件開始工作，相當于向容器插件發送插件觸發請求。

在步驟203中，容器插件根據所述觸發請求，獲取所述目標設備的設備信息和驅動。

例如，圖1中的容器插件16在偵聽到docker進程創建volume事件的觸發后，可以判斷觸發參數是否正確，比如可以是，觸發請求中攜帶的參數格式是否正確。若不符合要求則可以向docker返回創建volume事件失敗，否則，可以繼續獲取infiniband設備的設備信息和驅動，本例子中可以是獲取圖1中的物理機infiniband設備的設備信息以及物理機infiniband驅動。

在步驟204中，容器插件將設備信息和驅動返回給容器引擎。

本步驟中，圖1中的容器插件16可以將獲取到的infiniband設備的設備信息和驅動返回給docker。

在步驟205中，容器引擎使用所述設備信息和驅動，創建攜帶所述目標設備的容器。例如，docker可以根據設備信息和驅動，進行infiniband設備的設備掛載和目錄掛載。

本例子的容器創建方法是一種將設備信息和驅動的獲取設計為插件化的方法，插件化是一種靈活輕量的工作模式，具有插拔特性，通常插拔過程對主流程不構成影響。本例子中，當容器引擎創建容器時，可以自動觸發本公開的容器插件代為收集目標設備的設備信息和驅動，這樣使得對于容器創建時所需信息的獲取更為快速和方便，并且，插件化的方式對容器中的業務不會產生影響。

此外，假設docker創建多個容器時，現有技術中可以將驅動直接安裝在各個容器中，當驅動版本更新時導致每個容器和鏡像都要隨之更新，而本例子的方法中，是由容器插件將驅動返回給創建容器的docker引擎，相當于多個容器共享一份驅動即可，docker在創建新容器時自動獲取插件返回的新版本驅動使用即可，非常方便。而且，容器插件可以將設備最新的驅動和設備信息返回至docker，可以使得docker兼容適配各個設備版本，由容器插件負責收集目標設備的驅動和設備信息，大大簡化了攜帶設備的容器的創建流程，使得容器對設備的使用實現更加靈活和方便。

在一個例子中，將進一步詳細描述圖1中的容器插件的結構和工作過程。

如圖3所示，例如，本公開的容器插件可以包括三個模塊，分別為：插件擴展觸發模塊31、驅動和設備選擇模塊32、以及驅動和設備收集模塊33。例如，插件擴展觸發模塊31可以是dockervolume插件擴展觸發模塊。容器插件的工作過程可以由上述的三個模塊配合執行，包括如下的三個階段：

第一階段：插件擴展觸發模塊的流程。

如圖4的示例，在步驟401中，插件擴展觸發模塊接收到插件觸發。

本步驟中，插件擴展觸發模塊可以偵聽是否要創建volume事件。當docker接收到容器創建請求時，可以觸發插件擴展觸發模塊創建volume事件。本例子中，插件擴展觸發模塊在接收到docker發送的創建volume事件的插件觸發請求后，可以繼續執行402，否則，可以繼續偵聽。

在步驟402中，插件擴展觸發模塊判斷觸發參數是否正確。

若觸發參數正確，則可以在步驟403中觸發驅動和設備選擇模塊執行下一階段的流程；否則，可以在步驟404中向docker返回創建volume事件失敗。

由圖4的流程可以看到，本例子的容器插件中的插件擴展觸發模塊，可以主要負責判斷是否接收到docker的插件觸發，是否要創建volume事件，即負責確定本容器插件是否要開始獲取設備信息和驅動的流程。

第二階段：驅動和設備選擇模塊的流程。

如圖5的示例，在步驟501中，驅動和設備選擇模塊接收觸發請求。

本步驟中，驅動和設備選擇模塊接收到插件擴展觸發模塊的觸發。

在步驟502中，驅動和設備選擇模塊判斷用戶是否傳入了指定的驅動版本。

例如，用戶可以在調度docker創建容器時，在容器創建請求中就指定驅動版本，那么docker也會在向插件擴展觸發模塊發送插件觸發請求時，攜帶上所述指定的驅動版本，同樣，插件擴展觸發模塊在觸發驅動和設備選擇模塊時，可以將用戶指定的驅動版本傳給驅動和設備選擇模塊。

本步驟中，若判斷結果為否，即用戶沒有傳入驅動版本，則可以直接執行步驟505，觸發驅動和設備收集模塊33進行驅動收集，當然，該驅動和設備收集模塊33也會收集設備信息。如果判斷結果為是，即用戶傳入了指定的驅動版本，則可以執行步驟503。

在步驟503中，驅動和設備選擇模塊調用驅動和設備收集模塊查詢驅動。

在步驟504中，判斷指定版本的驅動是否存在。

本步驟中，可以是向驅動和設備收集模塊查詢是否存在所述指定的驅動版本，如不存在，可以執行步驟506，否則，可以執行步驟505。

在步驟505中，驅動和設備選擇模塊觸發驅動和設備收集模塊，以進入下一階段的流程，進行設備信息和驅動的收集。

在步驟506中，驅動和設備選擇模塊返回創建失敗，即驅動和設備選擇模塊向插件擴展觸發模塊返回失敗，繼而插件擴展觸發模塊向docker返回失敗。

由圖5的流程可以看到，本例子的容器插件中的驅動和設備選擇模塊，可以主要負責判斷是否要繼續觸發設備信息和驅動的收集獲取，如果指定版本的驅動并不存在，則不用繼續收集，直接向docker返回失敗即可，如果指定驅動存在或者未指定驅動，則可以觸發設備信息和驅動的收集。

第三階段：驅動和設備收集模塊的流程。

如圖6的示例，在步驟601中，驅動和設備收集模塊接收觸發請求。

本步驟中，驅動和設備收集模塊接收到驅動和設備選擇模塊的觸發。

在步驟602中，驅動和設備收集模塊判斷是否帶有指定的驅動版本。

如果判斷結果為否，即不帶驅動版本，用戶未指定，則可以執行步驟604；否則，若判斷結果為是，則可以執行步驟603。

在步驟603中，驅動和設備收集模塊判斷指定版本的驅動在緩存中是否存在。若存在，則執行步驟604；否則，可以執行步驟605。

在步驟604中，驅動和設備收集模塊由緩存中獲取最新的所述設備信息和驅動。本步驟中，獲取設備信息和驅動后，驅動和設備收集模塊可以將設備信息和驅動返回給驅動和設備選擇模塊，驅動和設備選擇模塊將設備信息和驅動返回給插件擴展觸發模塊，最終由插件擴展觸發模塊返回給docker進行攜帶infiniband設備的容器的創建。

在步驟605中，驅動和設備收集模塊判斷是否首次收集該版本驅動。

若非首次收集，則說明該驅動不存在，可以直接執行步驟608；若是首次收集，則可以執行步驟606。

在步驟606中，驅動和設備收集模塊調用驅動設備查詢器收集設備信息和驅動。該驅動設備查詢器的結構和工作原理，后續例子描述。

在步驟607中，驅動和設備收集模塊在接收到驅動設備查詢器返回的設備信息和驅動后，更新緩存中的驅動和設備信息。

本步驟中更新緩存后，驅動和設備收集模塊可以返回步驟603，再次判斷指定版本驅動是否在緩存中，若還是不存在，則依據上述流程描述，將返回失敗，當然還可以是依次經由上述的驅動和設備選擇模塊、插件擴展觸發模塊，最終返回失敗給docker；若再次判斷時已經存在，則依據上述流程描述，則將設備信息和驅動返回給docker即可。

在步驟608中，驅動和設備收集模塊返回創建失敗。

由圖6的流程可以看到，本例子的容器插件中的驅動和設備收集模塊，可以主要負責具體的設備信息和驅動的收集獲取，而且可以是優先由緩存中獲取，緩存中沒有時可以調用驅動設備查詢器獲取。

在一個例子中，上述提到的驅動設備查詢器，可以作為驅動和設備收集模塊的一部分，主要負責獲取容器插件所在的處理設備上的目標設備的設備信息和驅動。圖7示例了該驅動設備查詢器的結構，如圖7所示，可以包括：版本維護器71、驅動信息管理器72、設備信息管理器73和物理設備調用器74。

例如，版本維護器71中可以維護有不同版本的infiniband設備的設備信息和驅動。并且，該版本維護器71中還可以維護不同版本的infiniband設備對應的驅動信息映射鍵和設備信息映射鍵，通過映射鍵可以查詢驅動信息管理器72、設備信息管理器73，在驅動信息管理器72中存儲有驅動的描述和獲取方式，設備信息管理器73存儲有設備信息的描述和獲取方式。

當驅動設備查詢器接收到調用請求后，可以先查詢請求獲取的驅動和設備信息是否存儲在版本維護器71中。如果存在，則可以直接返回給驅動和設備收集模塊；如果不存在，可以通過該版本的映射鍵，查詢驅動信息管理器72和設備信息管理器73，得到設備信息和驅動的獲取方式。接著，可以通過物理設備調用器74(例如，infiniband物理設備調用器)根據所述的獲取方式，獲得具體的設備信息和驅動。并且，還可以將獲取到的設備信息和驅動存儲至所述版本維護器71中，下次就可以直接由版本維護器71中獲取。

本例子中，驅動和設備收集模塊中可以自動運行一個定時器，定時調用驅動設備查詢器來進行驅動的定時檢查和更新，以保證物理驅動更新后能夠同步至容器插件中。這樣用戶創建容器時可以無需關心驅動版本和設備，最合適的驅動文件會靈活地注入容器內部、相應的設備會自動掛載至容器內。同時，通過驅動設備查詢器查詢當前處理設備使用的目標設備的版本，可以做到兼容和適配各種版本的infiniband設備。

為了實現本公開的容器創建方法，本公開還提供了一種容器創建裝置，該裝置可以應用于攜帶目標設備的容器的創建，該裝置可以應用于容器插件。如圖8所示，該裝置可以包括：觸發接收單元81、信息獲取單元82和信息反饋單元83。其中，需要說明的是，上述的三個單元可以是容器創建裝置在邏輯功能上的劃分，實際的裝置結構設計中包括這三個單元對應的邏輯功能即可，不一定嚴格按照這三個單元的劃分來設計。例如，圖3的容器插件中，插件擴展觸發模塊可以相當于上述的觸發接收單元81，可以實現觸發接收單元81對應的邏輯功能；而信息獲取單元82的邏輯功能可以由圖3的驅動和設備選擇模塊、驅動和設備收集模塊功能實現。

觸發接收單元81，用于接收用于創建容器的容器引擎發送的插件觸發請求；

信息獲取單元82，用于根據觸發請求，獲取目標設備的設備信息和驅動；

信息反饋單元83，用于將所述設備信息和驅動返回給所述容器引擎，以使得所述容器引擎創建攜帶所述目標設備的容器。

在一個例子中，如圖9所示，所述信息獲取單元82，包括：

版本判斷子單元821，用于判斷插件觸發請求中是否包括指定的驅動版本；

信息收集子單元822，用于當判斷結果為否，或者判斷結果為是且確定所述驅動版本的驅動存在時，收集所述設備信息和驅動。

在一個例子中，信息收集子單元822，具體用于：當判斷結果為否時，則由緩存中獲取最新的所述設備信息和驅動；當判斷結果為是，且確定所述驅動版本的驅動在所述緩存中存在時，則獲取所述緩存中的設備信息和驅動；當判斷結果為是，且確定所述驅動版本的驅動在緩存中不存在并且是首次收集時，則調用驅動設備查詢器收集所述設備信息和驅動，并將收集到的設備信息和驅動放入所述緩存。

在一個例子中，信息收集子單元822，在用于調用驅動設備查詢器收集所述設備信息和驅動，并將收集到的設備信息和驅動放入所述緩存時，包括：查詢所述驅動設備查詢器的版本維護器中是否存儲所述設備信息和驅動；若不存在，則由維護的信息管理器中獲取所述設備信息和驅動的獲取方式，并由物理設備調用器根據所述獲取方式獲得所述設備信息和驅動；將所述設備信息和驅動存儲至所述版本維護器。

為了實現本公開的容器創建方法，本公開還提供了一種容器創建裝置，該裝置可以應用于攜帶目標設備的容器的創建，該裝置可以應用于容器引擎。如圖10所示，該裝置可以包括：請求發送模塊1001、信息接收模塊1002和容器創建模塊1003。

請求發送模塊1001，用于向容器插件發送插件觸發請求，所述插件觸發請求用于觸發所述容器插件獲取所述目標設備的設備信息和驅動；

信息接收模塊1002，用于接收所述容器插件返回的所述設備信息和驅動；

容器創建模塊1003，用于使用設備信息和驅動，創建攜帶目標設備的容器。

上述實施例闡明的裝置或模塊，具體可以由計算機芯片或實體實現，或者由具有某種功能的產品來實現。一種典型的實現設備為計算機，計算機的具體形式可以是個人計算機、膝上型計算機、蜂窩電話、相機電話、智能電話、個人數字助理、媒體播放器、導航設備、電子郵件收發設備、游戲控制臺、平板計算機、可穿戴設備或者這些設備中的任意幾種設備的組合。

為了描述的方便，描述以上裝置時以功能分為各種模塊分別描述。當然，在實施本公開時可以把各模塊的功能在同一個或多個軟件和/或硬件中實現。

本領域內的技術人員應明白，本公開的實施例可提供為方法、系統、或計算機程序產品。因此，本公開可采用完全硬件實施例、完全軟件實施例、或結合軟件和硬件方面的實施例的形式。而且，本公開可采用在一個或多個其中包含有計算機指令的計算機可讀存儲介質(包括但不限于磁盤存儲器、cd-rom、光學存儲器等)上實施的計算機程序產品的形式。

這些計算機程序指令也可裝載到計算機或其他可編程數據處理設備上，使得在計算機或其他可編程設備上執行一系列操作步驟以產生計算機實現的處理，從而在計算機或其他可編程設備上執行的指令提供用于實現在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。例如，所述介質上存儲的計算機指令被處理器執行時可以實現以下步驟：接收用于創建容器的容器引擎發送的插件觸發請求；根據所述觸發請求，獲取所述目標設備的設備信息和驅動；將所述設備信息和驅動返回給所述容器引擎，以使得所述容器引擎創建攜帶所述目標設備的容器。

在一個典型的配置中，本公開中的處理設備還可以包括一個或多個處理器(cpu)、存儲器，以及存儲在存儲器上并可在處理器上運行的計算機指令，所述計算機指令包括：用于實現容器插件的插件指令、以及用于實現容器引擎的引擎指令。

所述處理器通過執行所述插件指令，用于實現如下步驟：接收用于創建容器的容器引擎發送的插件觸發請求；根據所述觸發請求，獲取所述目標設備的設備信息和驅動；將所述設備信息和驅動返回給所述容器引擎；

所述處理器通過執行所述引擎指令，用于實現如下步驟：向容器插件發送插件觸發請求，所述插件觸發請求用于觸發所述容器插件獲取所述目標設備的設備信息和驅動；接收所述容器插件返回的設備信息和驅動；使用所述設備信息和驅動，創建攜帶所述目標設備的容器。

以上所述僅為本公開的較佳實施例而已，并不用以限制本公開，凡在本公開的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本公開保護的范圍之內。