一种容器创建方法和装置与流程

本公开涉及网络技术领域，特别涉及一种容器创建方法和装置。

背景技术：

容器技术是一种操作系统层虚拟化技术，可以将应用软件系统打包成一个软件容器，内含应用本身的代码及其所需要的操作系统核心和库，通过命名空间技术和硬件资源隔离技术创造出应用独立的沙箱运行环境。目前，随着人工智能和图像处理业务的发展和需求扩大，容器技术也逐步应用于企业高性能计算领域方面的工作。例如，在高性能计算领域，容器中运行的应用有时需要使用某个物理设备，那么为了使得能够使用该物理设备，创建的容器中需要包括该物理设备的信息，比如，可以是设备的驱动，否则容器就无法使用该设备。

现有技术的其中一种方式，可以将设备的驱动直接安装在容器中，每个容器中都要安装该驱动，但是这种方式在驱动版本升级时，所有的容器和镜像都要更新，而且还需要获取更新时所需要的设备信息，操作非常繁琐，而且还会对容器中的业务运行造成影响。

技术实现要素：

有鉴于此，本公开提供一种容器创建方法和装置，以使得容器对设备的使用实现更加灵活和方便，并减小设备更新对容器业务的影响。

具体地，本公开是通过如下技术方案实现的：

第一方面，提供一种容器创建方法，所述方法应用于携带目标设备的容器的创建，所述方法包括：

接收用于创建容器的容器引擎发送的插件触发请求；

根据所述触发请求，获取所述目标设备的设备信息和驱动；

将所述设备信息和驱动返回给所述容器引擎，以使得所述容器引擎创建携带所述目标设备的容器。

第二方面，提供一种容器创建方法，所述方法应用于携带目标设备的容器的创建，所述方法包括：

向容器插件发送插件触发请求，所述插件触发请求用于触发所述容器插件获取所述目标设备的设备信息和驱动；

接收所述容器插件返回的所述设备信息和驱动；

使用所述设备信息和驱动，创建携带所述目标设备的容器。

第三方面，提供一种容器创建装置，所述装置应用于携带目标设备的容器的创建，所述装置包括：

触发接收模块，用于接收用于创建容器的容器引擎发送的插件触发请求；

信息获取模块，用于根据所述触发请求，获取目标设备的设备信息和驱动；

信息反馈模块，用于将所述设备信息和驱动返回给所述容器引擎，以使得所述容器引擎创建携带所述目标设备的容器。

第四方面，提供一种容器创建装置，所述装置应用于携带目标设备的容器的创建，所述装置包括：

请求发送模块，用于向容器插件发送插件触发请求，所述插件触发请求用于触发所述容器插件获取所述目标设备的设备信息和驱动；

信息接收模块，用于接收所述容器插件返回的所述设备信息和驱动；

容器创建模块，用于使用所述设备信息和驱动，创建携带目标设备的容器。

第五方面，提供一种计算机可读存储介质，所述介质上存储有计算机指令，该指令被处理器执行时实现以下步骤：

接收用于创建容器的容器引擎发送的插件触发请求；

根据所述触发请求，获取所述目标设备的设备信息和驱动；

将所述设备信息和驱动返回给所述容器引擎，以使得所述容器引擎创建携带所述目标设备的容器。

第六方面，提供一种处理设备，所述处理设备中安装有目标设备，所述处理设备包括存储器、处理器，以及存储在存储器上并可在处理器上运行的计算机指令，所述计算机指令包括：用于实现容器插件的插件指令、以及用于实现容器引擎的引擎指令；

所述处理器通过执行所述插件指令，用于实现如下步骤：接收用于创建容器的容器引擎发送的插件触发请求；根据所述触发请求，获取所述目标设备的设备信息和驱动；将所述设备信息和驱动返回给所述容器引擎；

所述处理器通过执行所述引擎指令，用于实现如下步骤：向容器插件发送插件触发请求，所述插件触发请求用于触发所述容器插件获取所述目标设备的设备信息和驱动；接收所述容器插件返回的设备信息和驱动；使用所述设备信息和驱动，创建携带所述目标设备的容器。

本公开的容器创建方法和装置，当容器引擎创建容器时，可以自动触发本公开的容器插件代为收集目标设备的设备信息和驱动，这样使得对于容器创建时所需信息的获取更为快速和方便，并且，插件化的方式对容器中的业务不会产生影响。

附图说明

图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)、存储器，以及存储在存储器上并可在处理器上运行的计算机指令，所述计算机指令包括：用于实现容器插件的插件指令、以及用于实现容器引擎的引擎指令。

所述处理器通过执行所述插件指令，用于实现如下步骤：接收用于创建容器的容器引擎发送的插件触发请求；根据所述触发请求，获取所述目标设备的设备信息和驱动；将所述设备信息和驱动返回给所述容器引擎；

所述处理器通过执行所述引擎指令，用于实现如下步骤：向容器插件发送插件触发请求，所述插件触发请求用于触发所述容器插件获取所述目标设备的设备信息和驱动；接收所述容器插件返回的设备信息和驱动；使用所述设备信息和驱动，创建携带所述目标设备的容器。

以上所述仅为本公开的较佳实施例而已，并不用以限制本公开，凡在本公开的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本公开保护的范围之内。