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

本申请涉及计算机技术领域，尤其涉及一种容器创建方法及装置。

背景技术：

目前，业务提供方(如：网站)后台的计算设备、存储设备等资源设备，能够向不同用户提供所需的资源。当不同用户调用同一资源设备中的资源时，可能会产生排队等待的现象，使得资源系统的工作效率偏低。

为了减少或避免上述问题，提出一种虚拟化技术，即容器。容器可认为是提供一个与宿主机操作系统共享内核但与操作系统中的其他进程资源相隔离的执行环境。通过容器方式，可将每个资源设备上的资源进行划分，得到相互隔离且可独立使用的资源单元，以便于不同的用户直接调用这些资源单元。其中，docker作为一种容器技术，得到了广泛应用。

现有技术中，为了便于用户以docker容器的方式调用资源设备上的资源，部分硬件厂商提供了一种docker组件，docker组件中包含docker命令行工具以及相应的硬件驱动工具，通过上述的docker组件，用户可以针对硬件资源创建出相应的硬件容器，在创建出硬件容器后，用户便可以通过该硬件容器调用资源设备上的硬件资源。

以图形处理器(graphicsprocessingunit，gpu)为例。如图1所示，针对某一gpu，用户可以通过nivdia-docker(英伟达-docker)的命令行工具，自行创建gpu容器，并且，通过nvidia-docker-plugin(英伟达-docker-插件)的工具，能够共享当前gpu的硬件驱动，使得创建出的gpu容器可以正常运行。

但是，gpu资源不同于中央处理器(centerprocessingunit，cpu)资源和内存资源，在创建gpu容器时不仅需要gpu资源数量和gpu设备型号属性，还需要gpu设备的具体使用属性，那么如何创建带有gpu特征的gpu容器成为亟需解决的重要问题。

技术实现要素：

本申请实施例提供一种容器创建方法及装置，用以解决如何创建带有gpu特征的gpu容器的问题。

本申请实施例提供的一种容器创建方法，包括：

获取用户发送的容器创建请求，所述容器创建请求中携带待创建容器所需要的资源信息；

根据所述资源信息，从资源设备中调用与所述资源信息相匹配的资源；

基于调用的所述资源创建容器。

本申请实施例另提供的一种容器创建方法，包括：

容器管理设备创建第一容器；

指示所述第一容器创建第二容器，其中，所述第一容器在获取容器创建请求后，根据所述容器创建请求中所携带的资源信息，从资源设备中调用与所述资源信息相匹配的资源，并基于调用的所述资源创建第二容器。

本申请实施例提供的一种容器创建装置，包括：

获取模块，获取用户发送的容器创建请求，所述容器创建请求中携带待创建容器所需要的资源信息；

调用模块，根据所述资源信息，从资源设备中调用与所述资源信息相匹配的资源；

容器创建模块，基于调用的所述资源创建容器。

本申请实施例另提供的一种容器创建装置，包括：

第一创建模块，创建第一容器；

第二创建模块，指示所述第一容器创建第二容器，其中，所述第一容器在获取容器创建请求后，根据所述容器创建请求中所携带的资源信息，从资源设备中调用与所述资源信息相匹配的资源，并基于调用的所述资源创建第二容器。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

对于能够提供资源的资源设备而言，预先创建第一容器，第一容器具有自行创建第二容器的功能，故当第一容器运行时，第一容器中的功能将启动，在此情况下，第一容器将获取由用户所发出的容器创建请求，容器创建请求会携带用户所需调用的资源的相关信息，即，资源信息，那么，第一容器将根据资源信息，在资源设备的可用资源中，调用与资源信息相匹配的资源，并基于调用到的资源，创建第二容器，第二容器可认为是资源设备中可用资源的独立划分，创建后的第二容器可直接被用户所调用。

相较于现有技术而言，本申请实施例中通过创建第一容器的方式，使得第一容器可以自动运行，即，可以自行根据用户的容器创建请求创建相应的第二容器供用户使用，这样的方式无需用户采用手动的方式创建资源容器，有效提升了创建资源容器的便捷性。同时，第一容器可以便捷地部署在不同的资源设备中，能够大规模自动化的应用，特别对于业务提供方后台的大量资源设备而言，能够有效降低人工部署所消耗的人力成本，便于实现对资源设备中的资源进行全局性调用。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为现有技术中创建gpu容器的过程；

图2a为本申请实施例提供的容器创建方法所基于的架构示意图；

图2b为本申请实施例提供的一种容器创建过程；

图3为本申请实施例提供的另一种容器创建过程；

图4为本申请实施例提供的第一容器中的功能架构的示意图

图5为本申请实施例提供的在实际应用场景下容器创建过程的第一阶段的步骤示意图；

图6a及6b为本申请实施例提供的两种不同的容器架构体系示意图；

图7为本申请实施例提供的gpu容器创建的示意图；

图8a及8b为本申请实施例提供的在实际应用场景下容器创建过程的第二阶段的步骤示意图；

图9为本申请实施例提供的一种容器创建装置结构示意图；

图10为本申请实施例提供的另一种容器创建装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本申请实施例中，所采用的架构可如图2a所示，在图2a中，不同的资源设备中可提供诸如gpu、内存、硬盘等资源，其中，所述的资源设备包括但不限于：服务器、计算机、数据库等设备。

而图中的docker管理中心，可以针对不同的资源设备创建相应的容器，当然，在实际应用中，所述的docker管理中心可以是具有docker容器创建权限的设备(如：服务器)，也可以是具有docker容器创建功能的应用程序(如：dockerswarm、apachemesos等)，这里并不作具体限定。应理解，针对图2a中的docker管理中心而言，无论是硬件设备还是软件程序，该docker管理中心均具有在架构中各资源设备上创建docker容器的权限。

基于图2a所示的架构，本申请实施例提供的容器创建过程如图2b所示，该过程具体包括以下步骤：

s201：容器管理设备创建第一容器。

所述的容器管理设备，可认为是如图2a所示架构中的docker管理中心。所述的第一容器，可认为是由容器管理设备针对资源设备所创建的一种docker容器。在本申请实施例中，第一容器内装载有相应的应用，其能够自行创建用户所需的资源容器，实现资源调用(后续将详细说明)。

当针对如图2a所示的架构中的资源设备均创建了第一容器后，由于该第一容器自身的应用功能，便可以获取由不同用户发出的容器创建请求。其中，所述的容器创建请求，可以是针对诸如gpu图形计算资源(以下简称为gpu资源)、cpu计算资源(以下简称为cpu资源)、内存资源、存储资源等资源的调用请求。

在本申请实施例中，容器创建请求可由需要使用资源的用户发出，其中通常会携带有用户所需资源的相关信息，即资源信息，作为本申请中的一种可能方式，资源信息中包含用户所要调用的资源的数量信息，同时，还可以包含资源类型等信息，这里并不构成对本申请的限定。可以理解地，通过本步骤确定的资源信息，将便于后续为该用户分配相应的资源。

s202：指示所述第一容器创建第二容器。

指示第一容器创建第二容器的过程，可认为是指示第一容器执行下述操作的过程：

指示第一容器在获取容器创建请求后，根据所述容器创建请求中所携带的资源信息，从资源设备中调用与所述资源信息相匹配的资源，并基于调用的所述资源创建第二容器。

所述的第二容器与前述第一容器不同，第二容器是一种资源容器，换言之，本申请实施例中的第二容器，实质上是资源设备所提供的资源的划分，进而形成容器，第二容器被创建后，用户可以直接进行使用。

当然，前述的第一容器和第二容器均是基于docker技术的docker容器，由于docker技术是一种较为成熟的虚拟化技术，故本申请实施例中针对第一容器和第二容器创建过程的技术底层实现不做过多赘述。

通过上述步骤，对于能够提供资源的资源设备而言，docker管理中心将针对各资源设备创建第一容器，第一容器具有自行创建第二容器的功能，故当第一容器运行时，第一容器中的功能将启动，在此情况下，第一容器将获取由用户所发出的容器创建请求，容器创建请求会携带用户所需调用的资源的相关信息，即，资源信息，那么，第一容器将根据资源信息，在资源设备的可用资源中，调用与资源信息相匹配的资源，并基于调用到的资源，创建第二容器，第二容器可认为是资源设备中可用资源的独立划分，创建后的第二容器可直接被用户所调用。

相较于现有技术而言，本申请实施例中通过创建第一容器的方式，使得第一容器可以自动运行，即，可以自行根据用户的容器创建请求创建相应的第二容器供用户使用，这样的方式无需用户采用手动的方式创建资源容器，有效提升了创建资源容器的便捷性。

此外，第一容器可以便捷地部署在不同的资源设备中，能够大规模自动化的应用，特别对于业务提供方后台的大量资源设备而言，能够有效降低人工部署所消耗的人力成本。

在实际应用中，容器管理设备创建第一容器，包括：所述容器管理设备使用dockerfile生成docker镜像，根据所述docker镜像，创建第一容器，该第一容器用于根据指示创建第二容器。

其中，docker镜像可认为是创建docker容器所需的文件集合，作为本申请实施例中的一种方式，docker镜像包括但不限于：配置文件、运行库、程序文件等。这里的配置文件、运行库可构成docker容器的运行环境，而程序文件指定了docker容器的功能。在本申请实施例中，通过dockerfile所生成的容器镜像中定义了插件容器功能，即，自行获取容器创建请求，并基于容器创建请求创建容器。

在本申请实施例中，所述第一容器可包括：插件容器。所述第二容器可包括：资源容器(如：gpu容器、cpu容器、内存容器等)。

对于第一容器创建第二容器的过程，本申请实施例中还提供一种容器创建方法，如图3所示，具体包括：

s301：获取用户发送的容器创建请求，所述容器创建请求中携带待创建容器所需要的资源信息。

在实际应用中，当用户需要使用相应的资源时，便可以向如图2a所示架构中的docker管理中心发出容器创建请求，再由docker管理中心将容器创建请求传递给前述的第一容器，使得第一容器创建资源容器。其中，容器创建请求中通常会包含用户所需的资源数量和资源类型，这里并不作具体限定。

s302：根据所述资源信息，从资源设备中调用与所述资源信息相匹配的资源；

需要说明的是，在本申请实施例的一种方式下，可针对某一资源设备中的资源进行调用，而在本申请实施例的另一种方式下，可针对各资源设备中的资源进行调用。这两种方式可以根据不同的实际应用场景而采用，这里并不构成对本申请的限定。

在进行资源调用的过程中，第一容器可以基于资源信息，为用户分配相匹配的资源。当然，每一资源设备能够提供相应的资源，实际操作时，部分资源可能已被其他用户调用，故本申请实施例中所要调用的资源，可以是资源设备中还未被使用的资源，也就是说，在确定出了用户所需的资源信息后，将在资源设备中当前还未被使用的资源中进行调用。

s203：基于所调用的资源创建容器。

调用到相应的资源后，便可以创建用户所需的容器，供用户使用。

基于以上内容可知，对于图2a所示的架构而言，上述过程可主要包括：创建第一容器，以及由第一容器创建第二容器两个阶段，为了清楚地描述这两个阶段，下面以用户获取gpu资源的场景进行详细说明(在该场景下，第一容器为插件容器，第二容器为gpu容器，两种容器均属于docker容器，其中，插件容器的功能架构如图4所示)。

第一阶段：创建第一容器。

在本申请实施例中，由于第一容器属于docker容器，故对第一容器的创建过程，可以通过容器镜像的方式进行创建，也即，如图4所示，使用dockerfile创建docker镜像，再根据docker镜像创建插件容器。

在实际应用场景下，该第一阶段的具体过程如图5所示，包括：

步骤s501：使用dockerfile创建docker镜像。

步骤s502：通过docker拉取docker镜像；

步骤s503：判断是否拉取成功，若是，则执行步骤s504；否则，执行步骤s502。

步骤s504：通过所述docker镜像，启动插件容器是否成功，若是，则执行步骤s505；否则，则执行步骤s501。

步骤s505：运行所述插件容器。

需要说明的是，所创建的容器可能包含两种情况：第一种情况，创建出的插件容器(即，第一容器)与资源设备是一对一的对应关系，也就是说，针对每一资源设备分别创建插件容器。

第二种情况，创建出的插件容器与资源设备是一对多的对应关系，也就是说，针对各资源设备创建统一的插件容器。

第二阶段：创建第二容器。

如图4所示，插件容器运行后，将自行获取用户发出的容器创建请求，实际操作时，用户向资源设备发送的容器创建请求，可采用超文本传输协议(hypertexttransferprotocol，http)的方式，所以，在本申请实施例中，获取容器创建请求，包括：监听用户的传输端口，当从所述传输端口中监听到容器创建请求时，获取该容器创建请求。

当然，在实际场景中，用户所发送的gpu容器创建请求也可能采用其他的网络传输协议，那么，在创建第一容器的容器镜像时，将定义第一容器所需监听的传输接口，具体将根据实际应用的需要进行调整，这里并不构成对本申请的限定。

在此需要说明的是，资源设备所接收到的用户请求并不仅限于上述的容器创建请求，还可能会接收到其他类型的请求，如：针对已创建的gpu容器的查询请求、使用请求等等，也就是说，第一容器持续监听资源设备的传输接口所获取到的请求，既有可能是容器创建请求，也可能是其他类型的请求。故在本申请实施例中，对于从传输接收所监听到的请求而言，第一容器将会进行判断。

具体而言，第一容器将判断监听到的请求是否携带了所要请求的gpu资源信息(如：所要请求的gpu资源数量信息、gpu类型信息等)，若是，则第一容器将监听到的请求确定为gpu容器创建请求并获取；否则，则第一容器调用docker进程接口，以使得docker进程对请求进行处理。

实际应用中，同一gpu资源设备可向多个用户提供gpu资源，也就是说，可能已有用户对当前的gpu资源设备中的gpu资源进行了调用，那么，此时第一容器获取到了新的gpu容器创建请求后，就需要确定当前gpu资源设备中可用的gpu资源是否能够满足该gpu容器创建请求所需。

此处，由于前述内容可知，所创建的第一容器可能有两种不同情况，分别对应不同的架构体系，不同架构体系中在调用资源的过程有一定差异，具体而言：

第一种架构体系，如图6a所示，在图6a中可见，第一容器唯一对应于一个资源设备(即，第一容器与资源设备满足一一对应关系)，此时，根据所述资源信息，从资源设备中调用与所述资源信息相匹配的资源，包括：根据与所控制的资源设备之间的映射关系，确定用于创建容器的目标资源设备，从所述目标资源设备中调用与所述资源信息相匹配的资源。

其中，从所述目标资源设备中调用与所述资源信息相匹配的资源，包括：确定所述资源信息对应的资源数量及资源类型，以及确定所述目标资源设备中的可用资源，从所述可用资源中，调用与所述资源数量及资源类型匹配的资源。

举例来说，假设针对资源设备a，用户发出的容器创建请求中，携带了所需的gpu型号(假设所需的型号a的gpu)以及gpu资源数量(假设所需的gpu资源数量为10)，那么，第一容器便会在资源设备a(此时，资源设备a便是目标资源设备)的可用gpu资源中，调用型号为a、数量为10的gpu资源。

实际操作时，第一容器可以通过调用docker接口的方式，获知当前资源设备中，所有gpu容器的使用情况，每个已创建的gpu容器上都会携带使用的gpu数量和型号的标签，那么，便可以根据标签来统计出当前机器的gpu使用情况，获取剩余可用的gpu资源型号和数目，此后，再查看是否满足用户请求的gpu数量和型号，若满足，则选定相应数量gpu(包含具体设备路径和型号)分配给该请求，并记录至该请求对应的设备列表中，这里并不构成对本申请的限定。

第二种体系，如图6b所示，在图6b中可见，第一容器对应于多个资源设备(即，第一容器与资源设备满足一对多的对应关系)，也就是说，该体系下的第一容器可以在全局对各资源设备中的gpu资源进行统一调用、分配。那么，根据所述资源信息，从资源设备中调用与所述资源信息相匹配的资源，包括：根据与所控制的资源设备之间的映射关系，确定用于创建容器的至少一个目标资源设备，从确定出的至少一个目标资源设备中调用与所述资源信息相匹配的资源。

其中，确定至少一个目标资源设备，包括：确定所述资源信息对应的资源数量及资源类型，从所控制的至少一个资源设备中，确定能够满足所述资源数量及资源类型的至少一个资源设备，作为目标资源设备。

例如：假设用户的gpu容器创建请求，需要调用两个a型号的gpu的资源，假设此时，资源设备a中包含一个型号为a的gpu，资源设备b中也包含一个型号为a的gpu，那么，便可以将资源设备a和b分别确定为目标设备。

在此基础上，从确定出的至少一个目标资源设备中调用与所述资源信息相匹配的资源，包括：确定不同的所述目标资源设备的可用资源，分别从不同的所述目标资源设备中调用资源，所述调用资源的总和满足所述资源信息对应的资源数量及资源类型。

延续上例，第一容器可以从资源设备a中调用一个a型号gpu，并从资源设备b中调用一个a型号gpu，从而满足了需要调用两个a型号的gpu资源的容器创建请求。

当然，针对该示例而言，在实际应用中，资源设备a中可能包含两个a型号的gpu，那么，则可以直接将资源设备a中的两个a型号gpu均进行调用。所以，作为本申请实施例中的一种方式，从确定出的总可用资源中，调用匹配于所述资源数量信息及资源类型信息的可用资源，包括：按照各资源设备的可用资源量从大到小的顺序，分别调用各资源设备中匹配于所述资源数量信息及资源类型信息的可用资源。

此外，在实际应用时，还可以按照比例进行资源调用。这里并不构成对本申请的限定。

无论采用上述的何种架构体系，在选定了相应的gpu后，第一容器会基于被选中的gpu的型号、数量、编号等信息生成资源参数。也即，基于调用的所述资源创建容器，包括：根据调用的所述资源，生成创建容器所需的资源参数，获取所述资源参数对应的挂载路径，根据所述资源参数以及所述挂载路径，调用docker进程创建容器。

当然，这里需要说明的是，创建的gpu容器对调用资源的资源设备相对应，具体而言，若创建gpu容器时，所调用的资源来自同一个资源设备，那么创建出的该gpu容器与该资源设备对应，而若创建gpu容器时，所调用资源来自多个资源设备，那么建出的该gpu容器将与多个资源设备对应。如图7所示。

对于挂载路径而言，获取所述资源参数对应的挂载路径，包括：判断所述资源参数对应的硬件驱动是否被挂载，若是，则获取挂载的所述硬件驱动的存储路径，作为挂载路径；否则，则获取所述资源参数对应的硬件驱动，存储在预先设定的驱动目录下，并根据该驱动目录生成硬件驱动的挂载路径。

这里的挂载，是指将资源设备上的gpu驱动挂接到插件容器中已存在的目录上。换言之，为了保证后续创建出的gpu容器能够正常运行并实现gpu的功能，通常gpu容器中会包含相应的gpu的驱动，而通过插件容器中的gpu驱动共享功能，能够自动为创建的gpu容器添加gpu驱动，因此，在插件容器中，将挂载相应的gpu驱动，才可实现gpu驱动的共享功能。

在实际应用场景下，该第二阶段的具体过程如图8a和8b所示，在图8a中，包括：

s801：监听用户传输接口，获取gpu容器创建请求中所请求的gpu数量和gpu型号。

s802：通过已创建的gpu容器所使用的gpu，确定资源设备中可用的gpu。

s803：若可用gpu不满足所请求的数量及型号，则返回失败；若可用的gpu满足所请求的数量及型号，则选定相应的gpu，并将选定的gpu加入设备列表。

s804：根据选定的gpu，生成创建gpu容器所需的资源参数，并调用docker进程。

在图8b中，包括：

s805：在容器创建请求包含盘卷驱动的情况下，通过盘卷驱动事件触发gpu驱动共享功能。

s806：判断gpu驱动是否被挂载，若是，则将gpu驱动在第一容器中的存储路径作为挂载路径；否则，则获取所述资源参数对应的gpu驱动存储在第一容器中预先设定的驱动目录下，并根据该驱动目录生成gpu驱动的挂载路径。

s807：将挂载路径发送给docker进程。

s808：确定资源参数正确，同时根据挂载路径，获得gpu驱动，根据资源参数和gpu驱动，创建gpu容器。

当然，对于上述过程，在实际应用场景下，docker进程获取到来源于插件容器的gpu容器创建请求后，会先判断该请求中携带的资源参数是否正确(如：资源参数的格式等)，若不正确则继续获取下一请求；若正确，则继续判断是否包含容器盘卷驱动，若不存在，则说明不需要加载gpu驱动，那么，docker进程将直接进行模拟gpu设备和创建gpu容器的操作。

若存在容器盘卷驱动，则通过盘卷驱动的创建卷和挂载卷的接口来调用触发插件容器中的gpu驱动共享功能，其中，gpu驱动共享功能会判断gpu驱动的卷挂载点是否存在，若不存在，则该gpu驱动共享功能会调用gpu工具获取gpu驱动并拷贝至预先设定的统一驱动目录，并生成一组挂载点的源路径和目标路径，返回给docker进程。若驱动目录直接存在，则直接将目录组合成源路径，再添加目标路径返回给docker进程。在docker进程中，会将获取的挂载点信息当做盘卷来进行挂载，即会把gpu驱动文件挂载入容器中使用。之后，再将创建容器传入的gpu设备信息模拟成容器内部的设备，然后创建gpu容器并启动。最后，便可得到了携带了需求gpu资源的容器。

当然，上述内容仅是以gpu容器为例所进行的说明，在实际应用中，同样适用于其他类型的资源容器，如：内容容器、cpu容器等等，这里并不构成对本申请的限定。

以上为本申请实施例提供的容器创建方法，基于同样的思路，本申请实施例还提供一种容器创建装置，如图9所示。该装置包括：

获取模块901，获取用户发送的容器创建请求，所述容器创建请求中携带待创建容器所需要的资源信息；

调用模块902，根据所述资源信息，从资源设备中调用与所述资源信息相匹配的资源；

容器创建模块903，基于调用的所述资源创建容器。

所述获取模块901，监听用户的传输端口，当从所述传输端口中监听到容器创建请求时，获取该容器创建请求。

在一种方式下，所述调用模块902，根据与所控制的资源设备之间的映射关系，确定用于创建容器的目标资源设备，从所述目标资源设备中调用与所述资源信息相匹配的资源。

进一步地，所述调用模块902，确定所述资源信息对应的资源数量及资源类型，以及确定所述目标资源设备中的可用资源，从所述可用资源中，调用与所述资源数量及资源类型匹配的资源。

在另一种方式下，所述调用模块902，根据与所控制的资源设备之间的映射关系，确定用于创建容器的至少一个目标资源设备，从确定出的至少一个目标资源设备中调用与所述资源信息相匹配的资源。

所述调用模块902，确定所述资源信息对应的资源数量及资源类型，从所控制的至少一个资源设备中，确定能够满足所述资源数量及资源类型的至少一个资源设备，作为目标资源设备。

所述调用模块902，确定不同的所述目标资源设备的可用资源，分别从不同的所述目标资源设备中调用资源，所述调用资源的总和满足所述资源信息对应的资源数量及资源类型。

所述容器创建模块903，根据调用的所述资源，生成创建容器所需的资源参数，获取所述资源参数对应的挂载路径，根据所述资源参数以及所述挂载路径，调用docker进程创建容器。

所述容器创建模块903，判断所述资源参数对应的硬件驱动是否被挂载，若是，则获取挂载的所述硬件驱动的存储路径，作为挂载路径，否则，则获取所述资源参数对应的硬件驱动，存储在预先设定的驱动目录下，并根据该驱动目录生成硬件驱动的挂载路径。

所述资源包括：图形处理器gpu资源、中央处理器cpu资源、内存资源、缓存资源、存储资源中的至少一种；所述容器包括：资源容器。

本申请实施例还提供一种容器创建装置，如图10所示。该装置包括：

第一创建模块1001，创建第一容器；

第二创建模块1001，指示所述第一容器创建第二容器，其中，所述第一容器在获取容器创建请求后，根据所述容器创建请求中所携带的资源信息，从资源设备中调用与所述资源信息相匹配的资源，并基于调用的所述资源创建第二容器。

所述第一创建模块1001，所述容器管理设备使用dockerfile生成docker镜像，根据所述docker镜像，创建第一容器，该第一容器用于根据指示创建第二容器。

所述第一容器包括：插件容器；所述第二容器包括：资源容器。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmablelogicdevice,pld)(例如现场可编程门阵列(fieldprogrammablegatearray，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardwaredescriptionlanguage，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advancedbooleanexpressionlanguage)、ahdl(alterahardwaredescriptionlanguage)、confluence、cupl(cornelluniversityprogramminglanguage)、hdcal、jhdl(javahardwaredescriptionlanguage)、lava、lola、myhdl、palasm、rhdl(rubyhardwaredescriptionlanguage)等，目前最普遍使用的是vhdl(very-high-speedintegratedcircuithardwaredescriptionlanguage)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定事务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行事务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。