CN108664291A - 容器组的构建方法和装置 - Google Patents

Abstract

本发明公开了一种容器组的构建方法和装置。其中，该方法包括：接收用于构建容器组的命令信息；根据命令信息对预设的配置文件进行解析，生成探针调用命令；基于探针调用命令，调用探针探测与容器组中待构建的当前容器具有依赖关系的容器的运行状态；判断运行状态不影响构建当前容器之后，构建当前容器。由此，本实施例可以通过调用探针来探测被依赖容器的运行状态，根据运行状态构建依赖容器，例如，创建、启动、停止或者删除容器，解决了容器打包工具构建容器组出现的异常问题，使得构建容器组时非常有条理、有逻辑性，提高了容器组的构建的质量。

Description

容器组的构建方法和装置

技术领域

本发明涉及云计算技术领域，尤其涉及一种容器组的构建方法和装置。

背景技术

随着通信技术的快速发展，云计算对人们的生活产生了越来越大的影响。docker容器以其轻量化，封装化，快速迭代等特性成为目前云计算机技术中最为火热的技术。各类应用往往通过在宿主机上部署功能不同的容器(一般每个容器只负责单一功能，运行单一进程)，并通过容器间的彼此交互完成相关任务。

申请人经研究发现：事实上容器间的配合工作与运行在宿主机上的普通进程一样，有着彼此依赖的关系。例如：容器化的web集群，启动顺序应该为数据库容器，web应用容器，负载均衡容器，且必须是数据库容器完全启动成功(容器本身+内部数据实例)后，web应用容器才应启动，并对外提供服务；容器停止或者退出时，也需要对有依赖关系的容器进行按顺序的逐一停止和退出操作，否则很容易造成数据不一致的问题。

现有容器的打包工具，例如docker compose、crane等工具，这些工具实现了在特定文件格式(json，yaml)中定义、创建和删除容器的相关命令，实现了容器的按顺序打包一体化启动和停止。但是这些工具都没有考虑容器中运行的业务应用状态的情况，而直接进行下一容器的操作。这就容易造成如下容器装配异常问题：

1)只是按照定义的顺序进行了容器的相关创建、启动和删除操作等，而没有关注容器中应用的状态，使得看似容器组启动成功，却无法使用应用。

2)无法快速定位容器包(组)启动或者退出异常的问题原因。例如，容器开始启动成功，运行很短一段时间后却退出了。

3)容器组退出时，没有进行应用进程的逻辑检查，容易造成数据的不一致的问题。

发明内容

为了解决现有的容器组构建异常的问题，提高容器组的构建质量，本发明实施例提供了一种容器组的构建方法和装置。

第一方面，提供了一种容器组的构建方法。该方法包括以下步骤：

接收用于构建容器组的命令信息；

根据命令信息对预设的配置文件进行解析，生成探针调用命令；

基于探针调用命令，调用探针探测与容器组中待构建的当前容器具有依赖关系的容器的运行状态；

判断运行状态不影响构建当前容器之后，构建当前容器。

第二方面，提供了容器组的构建装置。该装置包括：

信息接收单元，用于接收用于构建容器组的命令信息；

文件解析单元，用于根据命令信息对预设的配置文件进行解析，生成探针调用命令；

状态探测单元，用于基于探针调用命令，调用探针探测与容器组中待构建的当前容器具有依赖关系的容器的运行状态；

容器构建单元，用于判断运行状态不影响构建当前容器之后，构建当前容器。

由此，本实施例可以通过调用探针来探测被依赖容器的运行状态，根据运行状态构建依赖容器，例如，创建、启动、停止或者删除容器，解决了容器打包工具构建容器组出现的异常问题，使得构建容器组时非常有条理、有逻辑性，提高了容器组的构建的质量。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍，显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一实施例的容器组构建***的框架图。

图2是本发明一实施例的容器组构建方法的流程示意图。

图3是本发明另一实施例的容器组构建方法的流程示意图。

图4是本发明一实施例的容器组构建装置的结构示意图。

具体实施方式

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

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图1是本发明一实施例的容器组构建***的框架图。

如图1所示，该***可以包括：url(Uniform Resource Locator，统一资源定位符)接口101、探针模块102、解析模块103、缓存模块104、主控模块105、容器API(ApplicationProgramming Interface，应用程序编程接口)106和OS(Operating System，操作***)调用接口107。

其中，url接口101可以通过命令行或者web接口发出容器组构建(或者装配)命令。探针模块102可以以文件目录形式组织，在目录结构分成通用目录。例如，网络类目录。例如，IP(网络之间互连的协议)目录、tcp(Transmission Control Protocol，传输控制协议)目录、udp(User Datagram Protocol，用户数据报协议)、http(HyperText TransferProtocol，超文本传输协议)等)。还例如，通用目录可以是数据库类(例如tnsping等)目录。又例如，通用目录可以是应用类目录。应用类目录中的探针需要用户自定义探针程序。

解析模块103可以用于解析进程，例如，根据用户命令以及配置文件将文件内容解析为容器调用命令和探针调用命令放入缓存模块104。缓存模块104可以是解析文件缓冲区，例如，既可以是文件也可是内存。

主控模块105可以顺序读取解析缓存模块104中的内容，还可以根据读取的内容进行容器相关操作。例如，若读取的内容不是探针调用命令，则可以不涉及容器内进程运行状态的判断，而可以直接调用容器命令或者容器API106进行容器操作；若读取的内容是探针调用命令，则可以为容器内进程运行状态进行判断，并将控制权转给探针程序。另外，主控模块105可以通过OS调用接口107对于探针返回的结果进行判断，若判断为true(容器构建正确)时，则装配下一容器；若为false(容器构建异常)则给出报错信息，并退出容器装配。

本领域的技术人员可以理解上述接口或者模块可以根据实际构建需要进行灵活设置，例如，接口可以通过命令行代替，用来获取相关指令或者数据。

下面各实施例均可以应用于本实施例的***架构逐一装配各个容器。本实施例的***可以作为下面各个实施例的实施主体执行具体的容器装配操作。为了描述简洁，各个实施例可以相互参考应用。

图2是本发明一实施例的容器组的构建方法的流程示意图。

如图2所示，该方法包括以下步骤：S210，接收用于构建容器组的命令信息；S220，根据命令信息对预设的配置文件进行解析，生成探针调用命令；S230，基于探针调用命令，调用探针探测与容器组中待构建的当前容器具有依赖关系的容器的运行状态；S240，判断运行状态不影响构建当前容器之后，构建当前容器。

在步骤S210中，容器组可以是docker容器组。可以理解，容器组还可以是计算机语言所编写的其他容器组，例如，Android(安卓)操作***的Java语言编写的容器组。构建容器组的命令可以是在特定文件格式(json、yarn)中定义、创建、装配容器的命令。配置文件可以由用户指定。配置文件可以包括各个容器名称、容器之间的依赖关系等参数。

容器组(容器包)中的各个容器有相互依赖关系，例如容器化的web集群，启动顺序应该为数据库容器，web应用容器，负载均衡容器，且必须是数据库容器完全启动成功(容器本身+内部数据实例)后，web应用容器才应启动，并对外提供服务；容器停止或者退出时，也需要对有依赖关系的容器进行按顺序的逐一停止和退出操作，否则很容易造成数据不一致性的问题。

在步骤S220中，对配置文件进行解析的实现方式例如：读取json格式或者yarn格式配置文件的内容，根据文件内容中相关调用参数生成对应的探针调用命令。相关调用参数例如为：主机名、IP地址、端口号等参数。调用的命令可以根据不同的指针类型做相应的调用。例如，通用类探针可以为***命令调用，对应参数可以为主机名(或者IP地址)+端口号；又例如，应用类探针根据具体业务场景由用户设置，比如curl命令调用，返回特定页面等。

在步骤S230中，探针的调用方式可以分为以下三种：

第一种：通过参数将探针的文件导入具有依赖关系的容器内进行探测；

第二种：通过宿主机直接对具有依赖关系的容器内的应用进行探测；

第三种：构建与当前容器在同一网络内的通用探针容器，利用通用探针容器进行探测。

容器的运行状态包括以下项中的至少一项：容器的启动状态、容器的停止状态、容器内进程的启动状态、容器内进程的停止状态等。

在步骤S240中，当判断出运行状态不影响构建当前容器时，再构建当前容器。

由此，本实施例可以通过调用探针来探测被依赖容器内进程的状态情况，根据进程的状态返回情况构建依赖容器，例如，创建、启动、停止或者删除容器，解决了容器打包工具构建容器组出现的异常问题，使得构建容器组时非常有条理、有逻辑性，提高了容器组的构建的质量。

作为图2实施例的第一个变形实施例，可以在图2所示实施例的基础上增加以下步骤：在用于构建容器组的配置文件中定义容器组中各个容器之间的依赖关系；设置用于探测定义了依赖关系的各个容器的运行状态的探针，生成预设的配置文件。该步骤可以增加在S220(对预设的配置文件进行解析)的步骤之前。

由此，本实施例可以通过在配置文件中提前定义容器的依赖关系以及选择合适的探针库文件(例如，/share/lib/app/getcul.sh，/isrunning.sh....../tcp/tcping.sh，/udp/updping.sh......)，然后自顶向下的调用外部探针库的相关探针(可以根据探测内容自行添加参数)来探测被依赖容器内进程的状态，进一步的根据进程的状态返回情况决定是否构建依赖容器。本实施例通过对探针库的调用很好的解决了docker容器打包工具只是对容器状态做判断而不对容器内运行进程做判断的问题，使得容器组的装配更加条理、更加具有逻辑性。

另外，探针库可以作为一个开源库，任何开发者都可以添加符合自己应用场景的探针模块，进一步扩扩展了本申请的使用范围。

作为图2实施例的第二个变形实施例，可以在图2所示实施例的基础上增加以下步骤：基于预设的等待时间、预设的探测次数和预设的递增时间差，探测与容器组中待构建的当前容器的具有依赖关系的容器的应用状态；判断预设的探测次数的探测结果是否符合预期；至少一个探测结果符合预期时，构建当前容器。该步骤可以增加在S230(调用探针探测与容器组中待构建的当前容器的具有依赖关系的容器的运行状态)的步骤之后。

例如，根据容器的特性，采用在n次探测内，只要一次成功即认为容器内进程状态正常的算法，另外，发起下次探测的时间，可以根据设置的初始时间参数和探针递增时间差获得。

本实施例可以采用探针多次探测的算法，多次进行探测。例如，在下一个容器启动或者停止之前，需要探测上一个容器的启动或者停止状态；又例如，在下一个容器内应用的启动或者停止之前，需要探测上一个容器内应用的启动或者停止状态。

由此，本实施例通过多次探测可以准确判断出运行状态是否影响构建当前容器时，防止***不稳定带来的探测误差，在精确探测的基础上再构建当前容器，进一步提高了构建当前容器的质量。

在一些实施例中，设置用于探测各个容器的运行状态的探针可以包括：基于各个容器的业务场景(例如，A业务需要先启动数据库容器，然后再启动web应用容器)，设置用于探测各个容器的运行状态的探针。

由此，本实施例可以根据具体的业务场景来设置指针，可以提高在该业务场景下指针探测的准确性，确保了后续的构建容器的质量。

图3是本发明另一实施例的容器组的构建方法的流程示意图。如图3所示，该方法包括以下步骤：

S310，根据配置文件格式要求定义容器装配文件(配置文件)。

例如，在配置文件中以从上至下的顺序明确容器的创建、启动顺序，即容器的依赖关系(例如，容器停止、删除、创建顺序等)。同时，配置文件中以import关键字在依赖容器的装配点设置需要进行探针调用。以目录+文件名的形式给出需要具体调用的探针文件。

S320，用户通过命令行或者接口(例如web接口)发出容器装配命令。

S330，解析进程根据用户命令以及配置文件将配置文件内容解析为容器调用命令和探针调用命令，并将解析出的容器调用命令和探针调用命令放入解析文件缓冲区(既可以是文件也可是内存)。

S340，主控执行进程顺序读取解析缓冲区内容，根据读取的内容进行构建容器的相关操作。

例如，若读取的内容不是探针调用命令，则不涉及容器内进程运行状态的判断，则直接调用容器命令或者API进行容器操作；若读取的内容是探针调用命令，则判断容器内进程运行状态，并将控制权转给探针程序。

S350，探针根据实际设定的参数(例如，主机名和端口号等)对依赖容器内的进程状态进行探测操作。

若探测结果符合预期(程序运行稳定，测探结果准确)，则进入S380；否则，进入转入S360。

S360，探针根据用户设定的等待时间m，探测次数n、探针递增时间差dt，准备发起n次探测。

其中，等待时间m、探测次数n、探针递增时间差dt等可以通过用户接口文件中的参数进行传递。

S370，若紧接着的一次探测符合预期结果，则转入S380；否则执行S360，直至探测次数大于n，返回探测失败结果。

S380，主控进程对于探针返回的结果进行判断，若为true则装配下一容器；若为false则给出报错信息，并退出容器装配。

重复步骤S340-S380的内容，实现全部容器组的装配。

需要说明的是，在不冲突的情况下，本领域的技术人员可以按实际需要将上述的操作步骤的顺序进行灵活调整，或者将上述步骤进行灵活组合等操作。为了简明，不再赘述各种实现方式。另外，各实施例的内容可以相互参考引用。

图4是本发明一实施例的容器组构建装置的结构示意图。

如图4所示，该装置400可以包括：信息接收单元410、文件解析单元420、探针探测单元430和容器构建单元440。其中，信息接收单元410可以用于接收用于构建容器组的命令信息；文件解析单元420可以用于根据命令信息对预设的配置文件进行解析，生成探针调用命令；探针探测单元430可以用于基于探针调用命令，调用探针探测与容器组中待构建的当前容器具有依赖关系的容器的运行状态；容器构建单元440可以用于判断出运行状态不影响构建当前容器时，构建当前容器。

需要说明的是，本实施例中所示的功能单元或者功能模块的实现方式可以为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM(EROM)、软盘、CD-ROM、光盘、硬盘、光纤介质、射频(RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

由此，本实施例可以通过调用探针来探测被依赖容器内进程的状态情况，根据进程的状态返回情况构建依赖容器，例如，创建、启动、停止或者删除容器，解决了容器打包工具构建容器组出现的异常问题，使得构建容器组时非常有条理、有逻辑性，提高了容器组的构建的质量。

在一些实施例中，容器组为docker容器组。

在一些实施例中，容器的运行状态包括以下项中的至少一项：容器的启动状态、容器的停止状态、容器内进程的启动状态、容器内进程的停止状态。

在一些实施例中，在图4实施例的基础上，还可以增加：文件生成单元。其中，文件生成单元可以用于在用于构建容器组的配置文件中定义容器组中各个容器之间的依赖关系；设置用于探测定义了依赖关系的各个容器的运行状态的探针，生成预设的配置文件。

在一些实施例中，文件生成单元还可以用于：基于各个容器的业务场景，设置用于探测各个容器的运行状态的探针。

在一些实施例中，状态探测单元还可以用于：通过参数将探针的文件导入具有依赖关系的容器内进行探测；或，通过宿主机直接对具有依赖关系的容器内的应用进行探测；或，构建与当前容器在同一网络内的通用探针容器，利用通用探针容器进行探测。

在一些实施例中，在图4实施例或者其变形实施例的基础上，还可以增加：补偿构建单元。其中，补偿构建单元可以用于基于预设的等待时间、预设的探测次数和预设的递增时间差，探测与容器组中待构建的当前容器的具有依赖关系的容器的应用状态；判断预设的探测次数的探测结果是否符合预期；至少一个探测结果符合预期时，构建当前容器。

需要说明的是，上述各实施例的装置可作为上述各实施例的用于各实施例的方法中的执行主体，可以实现各个方法中的相应流程，为了简洁，此方面内容不再赘述。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (14)

1.一种容器组的构建方法，其特征在于，包括以下步骤：

接收用于构建容器组的命令信息；

根据所述命令信息对预设的配置文件进行解析，生成探针调用命令；

基于所述探针调用命令，调用探针探测与所述容器组中待构建的当前容器具有依赖关系的容器的运行状态；

判断所述运行状态不影响构建所述当前容器之后，构建所述当前容器。

2.根据权利要求1所述的方法，其特征在于，所述对预设的配置文件进行解析之前，还包括：

在用于构建容器组的配置文件中定义所述容器组中各个容器之间的依赖关系；

设置用于探测定义了所述依赖关系的所述各个容器的运行状态的探针，生成所述预设的配置文件。

3.根据权利要求2所述的方法，其特征在于，所述设置用于探测所述各个容器的运行状态的探针，包括：

基于所述各个容器的业务场景，设置用于探测所述各个容器的运行状态的探针。

4.根据权利要求1所述的方法，其特征在于，所述调用探针探测，包括：

通过参数将探针的文件导入所述具有依赖关系的容器内进行探测；

或，

通过宿主机直接对所述具有依赖关系的容器内的应用进行探测；

或，

构建与所述当前容器在同一网络内的通用探针容器，利用所述通用探针容器进行探测。

5.根据权利要求1所述的方法，其特征在于，所述容器的运行状态包括以下项中的至少一项：

所述容器的启动状态、所述容器的停止状态、所述容器内进程的启动状态、所述容器内进程的停止状态。

6.根据权利要求1-5中任一项所述的方法，其特征在于，所述调用探针探测与所述容器组中待构建的当前容器的具有依赖关系的容器的运行状态之后，还包括：

基于预设的等待时间、预设的探测次数和预设的递增时间差，探测与所述容器组中待构建的当前容器的具有依赖关系的容器的应用状态；

判断所述预设的探测次数的探测结果是否符合预期；

至少一个探测结果符合预期时，构建所述当前容器。

7.根据权利要求1-5中任一项所述的方法，其特征在于，所述容器组为docker容器组。

8.一种容器组的构建装置，其特征在于，包括：

信息接收单元，用于接收用于构建容器组的命令信息；

文件解析单元，用于根据所述命令信息对预设的配置文件进行解析，生成探针调用命令；

探针探测单元，用于基于所述探针调用命令，调用探针探测与所述容器组中待构建的当前容器具有依赖关系的容器的运行状态；

容器构建单元，用于判断所述运行状态不影响构建所述当前容器之后，构建所述当前容器。

9.根据权利要求8所述的装置，其特征在于，还包括：

文件生成单元，用于在用于构建容器组的配置文件中定义所述容器组中各个容器之间的依赖关系；设置用于探测定义了所述依赖关系的所述各个容器的运行状态的探针，生成所述预设的配置文件。

10.根据权利要求9所述的装置，其特征在于，所述文件生成单元还用于：

基于所述各个容器的业务场景，设置用于探测所述各个容器的运行状态的探针。

11.根据权利要求8所述的装置，其特征在于，所述状态探测单元还用于：

通过参数将探针的文件导入所述具有依赖关系的容器内进行探测；

或，

通过宿主机直接对所述具有依赖关系的容器内的应用进行探测；

或，

构建与所述当前容器在同一网络内的通用探针容器，利用所述通用探针容器进行探测。

12.根据权利要求8所述的装置，其特征在于，所述容器的运行状态包括以下项中的至少一项：

所述容器的启动状态、所述容器的停止状态、所述容器内进程的启动状态、所述容器内进程的停止状态。

13.根据权利要求8-12中任一项所述的装置，其特征在于，还包括：

补偿构建单元，用于基于预设的等待时间、预设的探测次数和预设的递增时间差，探测与所述容器组中待构建的当前容器的具有依赖关系的容器的应用状态；判断所述预设的探测次数的探测结果是否符合预期；至少一个探测结果符合预期时，构建所述当前容器。

14.根据权利要求8-12中任一项所述的装置，其特征在于，所述容器组为docker容器组。