CN114461304A - 配置文件的确定方法和装置、存储介质及电子设备 - Google Patents

Abstract

本发明公开了一种配置文件的确定方法和装置、存储介质及电子设备。其中，该方法包括：获取目标应用的配置项参数，并根据配置项参数在目标数据库中进行查询，得到目标应用的应用模版文件；解析应用模版文件，得到应用模版文件包括的多个子模版和每一个子模版的层级信息，其中，每一个子模版的层级信息用于指示每一个子模版在应用模版文件中的层级；依据每一个子模版的层级信息，对多个子模版中每一个子模版进行逐层部署，并对部署完成的每一个子模版加载对应的资源文件；根据资源文件在每一个子模版中的加载信息确定用于运维目标应用的配置文件，解决了现有技术中无法对复杂应用进行资源编排，并对应用资源进行有序部署的技术问题。

Description

配置文件的确定方法和装置、存储介质及电子设备

技术领域

本发明涉及云计算及容器云技术领域，尤其涉及容器云运行时管理技术，具体而言，涉及一种配置文件的确定方法和装置、存储介质及电子设备。

背景技术

Kubernetes是一个容器编排平台，实现容器全生命周期管理，弹性伸缩，运维监控等基本功能，提供了多种容器编排对象，如Deployment，Statefulset，DeamonSet，Job等工作负载资源，还有多种基础配置资源的封装，如ConfigMap，Secret，Service等。Kubernetes主要专注于容器的编排和调度，管理的是单个服务和组件。而对于用户来说，更加关心的是整个应用的编排和运行时管理，包含多容器和服务的组合，管理他们的之间的依赖关系。Kubernetes需要使用yaml配置文件定义资源，对于复杂的应用，往往包含几十个服务，服务之间有复杂的依赖关系。随着服务数量的增多，描述一个应用需要组合使用大量的kubernetes资源，使用yaml文件描述多个服务的资源不仅十分繁琐，还容易出错。同时原生Kubernetes的yaml资源定义不支持服务依赖关系的描述，无法使应用的服务按依赖关系顺序部署。

相关技术的编排方案中，比较流行的是Helm基于Charts包的资源管理方案。可以在Templates里定义服务资源描述的模版，可以在requirements.yaml中描述服务依赖关系，能够简化应用的模版化定义描述，但helm模版语法定义复杂，难以图形化，虽然提供依赖关系描述，但只是关联出依赖的Charts包，并不支持运行时对服务依赖关系的处理，也无法使服务按依赖关系顺序部署。

针对上述的问题，现有技术中无法对复杂应用进行资源编排，并对应用资源进行有序部署等问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种配置文件的确定方法和装置、存储介质及电子设备，以至少解决现有技术中无法对复杂应用进行资源编排，并对应用资源进行有序部署等问题。

根据本发明实施例的一个方面，提供了一种配置文件的确定方法，包括：获取目标应用的配置项参数，并根据所述配置项参数在目标数据库中进行查询，得到所述目标应用的应用模版文件；解析所述应用模版文件，得到所述应用模版文件包括的多个子模版和每一个子模版的层级信息，其中，所述每一个子模版的层级信息用于指示所述每一个子模版在所述应用模版文件中的层级；依据所述每一个子模版的层级信息，对所述多个子模版中每一个子模版进行逐层部署，并对部署完成的所述每一个子模版加载对应的资源文件；根据所述资源文件在所述每一个子模版中的加载信息确定用于运维所述目标应用的配置文件。

根据本发明实施例的另一方面，还提供了一种配置文件的确定方法装置，包括：获取模块，用于获取目标应用的配置项参数，并根据所述配置项参数在目标数据库中进行查询，得到所述目标应用的应用模版文件；解析模块，用于解析所述应用模版文件，得到所述应用模版文件包括的多个子模版和每一个子模版的层级信息，其中，所述每一个子模版；部署模块，用于依据所述每一个子模版的层级信息，对所述多个子模版中每一个子模版进行逐层部署，并对部署完成的所述每一个子模版加载对应的资源文件；确定模块，用于根据所述资源文件在所述每一个子模版中的加载信息确定用于运维所述目标应用的配置文件。

根据本发明实施例的又一方面，还提供了一种计算机可读的存储介质，该计算机可读的存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行任一项方法实施例中的方法。

根据本发明实施例的又一方面，还提供了一种电子设备，包括存储器和处理器，上述存储器中存储有计算机程序，上述处理器被设置为通过所述计算机程序执行上述的任一项方法实施例中的方法。

在本发明实施例中，获取目标应用的配置项参数，并根据配置项参数在目标数据库中进行查询，得到目标应用的应用模版文件；解析应用模版文件，得到应用模版文件包括的多个子模版和每一个子模版的层级信息，其中，每一个子模版的层级信息用于指示每一个子模版在应用模版文件中的层级；依据每一个子模版的层级信息，对多个子模版中每一个子模版进行逐层部署，并对部署完成的每一个子模版加载对应的资源文件；根据资源文件在每一个子模版中的加载信息确定用于运维目标应用的配置文件，即使用了层级依赖结构来描述应用中服务的依赖关系，极大的简化了依赖关系描述的数据结构，使得部署目标应用的处理逻辑也变得相对简单，可以方便得实现运行时目标应用的实例拓扑结构的图形化展示，进而达到了对复杂的目标应用进行资源编排的目的，从而实现了对目标应用进行有效且快速的自动化部署运维的技术效果，进而解决了现有技术中无法对复杂应用进行资源编排，并对应用资源进行有序部署的技术问题。

附图说明

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

图1是根据本发明实施例的一种配置文件的确定方法的计算机终端的硬件结构框图；

图2为根据本发明实施例的配置文件的确定方法的流程图；

图3为本发明可选实施例的服务模版的结构示意图；

图4为根据本发明可选实施例的层级依赖的结构示意图；

图5为根据本发明可选实施例的应用部署方法的流程图；

图6是根据本发明实施例的一种配置文件的确定装置的结构示意图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请实施例所提供的方法实施例可以在计算机终端、移动终端或者类似的运算装置中执行。以运行在计算机终端上为例，图1是本发明实施例的一种配置文件的确定方法的计算机终端的硬件结构框图。如图1所示，计算机终端10可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104，可选地，上述计算机终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述计算机终端的结构造成限定。例如，计算机终端10还可包括比图1中所示更多或者更少的组件，或者具有与图1所示等同功能或比图1所示功能更多的不同的配置。

存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本发明实施例中的配置文件的确定方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。

根据本发明实施例的一个方面，提供了一种配置文件的确定方法，可选地，作为一种可选的实施方式，上述配置文件的确定方法可以但不限于应用于如图1所示的环境中。

可选地，在本实施例中，上述终端设备可以是配置有目标客户端的终端设备，可以包括但不限于以下至少之一：手机(如Android手机、iOS手机等)、笔记本电脑、平板电脑、掌上电脑、MID(Mobile Internet Devices，移动互联网设备)、PAD、台式电脑、智能电视等。目标客户端可以是视频客户端、即时通信客户端、浏览器客户端、教育客户端等。上述网络可以包括但不限于：有线网络，无线网络，其中，该有线网络包括：局域网、城域网和广域网，该无线网络包括：蓝牙、WIFI及其他实现无线通信的网络。上述服务器可以是单一服务器，也可以是由多个服务器组成的服务器集群，或者是云服务器。上述仅是一种示例，本实施例中对此不作任何限定。

作为一种可选的实施方式，如图2所示，上述配置文件的确定方法包括：

步骤S202，获取目标应用的配置项参数，并根据所述配置项参数在目标数据库中进行查询，得到所述目标应用的应用模版文件；

可选的，目标数据库中的应用模版文件是需要预先定义的，具体的，预先定义的应用模版由模版元数据，服务模版列表，配置输入参数列表，输出参数列表组成。配置输入参数是将应用中常变的值以变量的形式替代，在部署时，通过应用模版+配置项的组合，方便用户部署相应应用到不同的环境中，其中，所述服务模版列表包括了多个子模版，每一个子模版由模版元数据，资源列表，配置输入参数列表，输出参数列表组成，所述模版元数据用于指示构成模版框架的字段，例如，字段可以是模板名称、模板版本、模板所属目录、模板描述和模板标签列表。

步骤S204，解析所述应用模版文件，得到所述应用模版文件包括的多个子模版和每一个子模版的层级信息，其中，所述每一个子模版的层级信息用于指示所述每一个子模版在所述应用模版文件中的层级完成的所述每一个子模版加载对应的资源文件；

步骤S206，依据所述每一个子模版的层级信息，对所述多个子模版中每一个子模版进行逐层部署，并对部署完成的所述每一个子模版加载对应的资源文件；

步骤S208，根据所述资源文件在所述每一个子模版中的加载信息确定用于运维所述目标应用的配置文件。

通过上述步骤，获取目标应用的配置项参数，并根据配置项参数在目标数据库中进行查询，得到目标应用的应用模版文件；解析应用模版文件，得到应用模版文件包括的多个子模版和每一个子模版的层级信息，其中，每一个子模版的层级信息用于指示每一个子模版在应用模版文件中的层级；依据每一个子模版的层级信息，对多个子模版中每一个子模版进行逐层部署，并对部署完成的每一个子模版加载对应的资源文件；根据资源文件在每一个子模版中的加载信息确定用于运维目标应用的配置文件，即使用了层级依赖结构来描述应用中服务的依赖关系，极大的简化了依赖关系描述的数据结构，使得部署目标应用的处理逻辑也变得相对简单，可以方便得实现运行时目标应用的实例拓扑结构的图形化展示，进而达到了对复杂的目标应用进行资源编排的目的，从而实现了对目标应用进行有效且快速的自动化部署运维的技术效果，进而解决了现有技术中无法对复杂应用进行资源编排，并对应用资源进行有序部署的技术问题。

需要说明的是，上述子模版以及应用模版文件可以显示为图形化编排，通过拖拽的方式进行拓扑视图的展示，继而当应用模版文件中的一个子模版出现问题后，可以快速查找到对应的启用失败的子模版，使得用户在部署目标应用时能够更加直观，能够快速定位依据层级间的依赖关系进行应用上线前的编排测试。

在一个示例性实施例中，所述解析所述应用模版文件，得到所述应用模版文件包括的多个子模版和每一个子模版的层级信息之后，所述方法还包括：获取所述每一个子模版对应的元数据的信息描述；根据所述每一个子模版对应的元数据的信息描述，确定所述每一个子模版的属性，其中，所述每一个子模版的属性用于指示所述每一个子模版的模版类型，所述每一个子模版的模版类型用于确定所述每一个子模版对应的资源文件的加载方式。

在一个示例性实施例中，所述根据所述每一个子模版对应的元数据的信息描述，确定所述每一个子模版的属性，包括：在所述多个子模版包括第一组子模版、且所述第一组子模版中的每一个子模版的属性指示的模版类型为服务模版的情况下，确定所述第一组子模版中的每一个子模版对应的逐层部署方式为直接部署；在所述多个子模版包括第二组子模版、且所述第二组子模版中的每一个子模版的属性指示的模版类型为子应用模版的情况下，确定所述第二组子模版中的每一个子模版对应的逐层部署方式为调用部署，其中，所述调用部署用于指示对已经编排好的其他应用通过嵌套方式进行递归调用。

简而言之，由于子模版的类型不同，在部署时需要的部署方式也不同，故需要根据模版元数据信息描述，判断子模版是服务模版还是子应用模版，如果是子应用模版，进行递归调用(即将已经编排好的其他应用模版，作为应用模版的组件编排进当前目标应用的模版中)，进行子应用模版的部署，等待子应用部署完成后，继续后面的流程。为保证部署性能，限制子应用模版嵌套层级为1。如果是服务模版，直接进行服务模版的部署。

上述步骤S206从对于目标应用对应子模版进行部署以及加载资源文件的方式有多种，在一个可选实施例中，可以通过以下方案实现：根据所述每一个子模版的层级信息，对所述多个子模版进行层级分类，得到多个子模版集合，其中，所述多个子模版中层级相同的子模版被分类成一个子模版集合，所述多个子模版集合中的每个子模版集合对应一个层级；从最小层级对应的子模版集合开始，根据层级顺序逐层部署不同层级对应的子模版集合，并在所述子模版集合部署完成后加载所述子模版集合中的子模版对应的资源文件。

可以理解的是，在对多个子模版进行部署以及对应资源文件的加载时，需要根据层级进行一层一层的加载，以保证不同层级之间的依赖关系，使得相关联的目标应用的功能之间建立对应的联系，明确了上一层的服务模版与下一层的服务模版的依赖关系。

在一个示例性实施例中，根据所述资源文件在所述每一个子模版中的加载信息确定用于运维所述目标应用的配置文件，包括：在所述目标应用的配置项参数不包括输入参数的情况下，获取所述每一个子模版的加载信息对应的参数描述信息，并根据所述参数描述信息确定所述每一个子模版的输入参数变量值；通过所述输入参数变量值替换所述每一个子模版的变量占位符，得到用于运维所述目标应用的所述配置文件；或者在所述目标应用的配置项参数包括输入参数的情况下，确定所述配置项参数中的输入参数名，将所述输入参数名在预设的参数库中进行匹配，得到所述配置项参数对应的目标输入参数变量值；通过所述目标输入参数变量值替换所述每一个子模版的变量占位符，得到用于运维所述目标应用的所述配置文件。

在一个示例性实施例中，根据所述参数描述信息确定所述每一个子模版的输入参数变量值，包括：在所述参数描述信息中携带的输入输出关系，且所述每一个子模版不属与最小层级的情况下，获取所述每一个子模版的引用描述；其中，所述引用描述中包括：加载的所述资源文件中包含的参数名和当前所述每一个子模版所在层级之前其他层级加载资源文件后每一个子模版的输出参数；确定所述其他层级加载资源文件后每一个子模版的输出参数对应的目标参数名与所述资源文件中包含的参数名匹配结果；在所述匹配结果指示所述资源文件中包含的参数名存在匹配的所述输出参数的情况下，将所述输出参数的具体参数值作为所述每一个子模版的输入参数变量值。

可选的，加载子模版的资源文件，从子模版输入参数描述中，解析输入输出关系描述，子模版输入参数来源包括：1)前面层级中依赖服务的输出参数，通过service.${serviceName}.output.{param}描述引用。2)前面层级中依赖子应用的输出参数通过subapp.${appName}.output.{param}描述引用。3)部署应用时输入的应用配置项输入参数，通过app.input.${param}。

可选的，在解析输入输出关系时，根据引用描述中服务名或子应用名，查找前面层级中已部署的服务实例或应用实例，再根据参数名，从输出参数中匹配到具体值，如果引用描述是应用配置项输入参数，就根据参数名直接从配置项输入参数中匹配具体值，获取该值(即输入参数变量值)后，作为子模版的输入参数，替换子模版中yaml资源文件(相当于本发明实施例中的配置文件)中的变量占位符，完成yaml资源文件的渲染。

在一个示例性实施例中，在根据所述资源文件在所述每一个子模版中的加载信息确定用于运维所述目标应用的配置文件之后，所述方法还包括：将所述配置文件发送至容器编排平台，并监听所述容器编排平台根据所述配置文件创建的工作负载就绪事件；其中，所述工作负载就绪事件用于确定所述目标应用对应功能的状态为上线状态；确定所述应用模版文件对应的所述工作负载就绪事件的创建数量；在所述创建数量大于所述多个子模版的个数的情况下，确定所述目标应用完成上线就绪。

例如，将渲染后的kubernetes yaml资源对象下发至容器编排平台kubernetes，优先创建volume(对象)，secret(敏感信息配置信息)，configmap(配置图)等配置资源，再创建deployment(调度)或statefulset(有状态集)等工作负载资源。本层级所有服务完成资源创建后，监听kubernetes关于本层级所有服务的工作负载就绪(Ready)事件，当某个服务的就绪事件上报后，就更新应用实例中该服务实例的状态为上线就绪，并判断本层级所有服务是否都已就绪，如果还未就绪，继续监听。本层级所有服务状态就绪后，进行下一层服务模版的部署，循环这一过程，直到所有层级部署完成。所有层级部署完成后，修改应用状态为上线就绪，整个部署流程结束。

为了更好的理解本发明实施例以及可选实施例的技术方案，以下结合示例对上述的配置文件的确定方法的流程进行解释说明，但不用于限定本发明实施例的技术方案。

作为一种可选的实施例，提供了一种基于kubernetes的应用编排部署方法及装置，其设计要点是使用模版元数据，模版资源列表，自定义参数列表定义应用模版，使用有向无环图定义资源的依赖关系，部署时从有向图中循环获取出度为0的顶点进行部署，资源被部署执行完成后，将资源对应顶点从有向图中移除，以促使后置资源的执行，从而实现运行时依赖的处理。

其次，上述只是实现了运行时应用实例拓扑结构的图形化展示，解决应用中各服务的依赖关系。一般来说，要简化复杂应用中各工作负载资源和配置资源的管理，就需要实现类似helm charts方式的模版化管理，将各种yaml文件按目录组织成一个文件集合。该方法使用有向无环图DAG的方式来描述服务之间的依赖关系，但在文件中将多个服务的yaml资源配置文件描述为DAG结构比较复杂，使用图形化方式编排生成或解析展示这类应用模版比较困难，对程序的性能消耗也比较严重。

再次，用了有向无环图描述服务的依赖关系，虽然解决了应用运行时部署服务顺序启动问题。但在应用模版资源yaml文件中描述服务的有向无环图数据结构较为复杂，根据图形化拓扑结构生成为模版资源yaml文件中描述，或者模版文件描述解析为图形化的实现逻辑复杂，也影响程序的性能。在运行时管理中，部署应用模版处理依赖关系时，要实现对图广度优先遍历，算法时间复杂度和空间复杂度为O(V+E)，而层级依赖的遍历复杂度为O(V),算法逻辑实现上也简单不少。在应用完成部署时间上，两者其实差不多，对应按依赖顺序部署的应用，整个完成时间是按最后一个服务启动就绪时间来算，应用完成部署时间可表示为：

t＝D×Max[S_t]；

其中，D在有向无环图结构中代表最大依赖深度，在层级依赖结构中代表最大层级数，对于同一个应用，两者是一样的；S_t在有向无环图结构中代表相同依赖深度服务中一个服务最大的就绪时间，在层级依赖结构中代表相同层级服务中一个服务最大的就绪时间，由于层级依赖结构没有区分具体依赖关系，同层服务数会比有向无环图多，但同层服务都是并发部署，两者S_t的时间也相差不大，因此，两种结构对应应用完成部署时间差别不大。

作为一种可选的实施例，还提供了基于容器云技术的服务编排与依赖关系管理方法和系统，其设计要点是为每一个应用中的服务配置多个初始化容器，其中每一初始化容器用于检测与该服务启动存在依赖关系的其他管理服务是否能够正常启动，基于对关联服务的探测结果以决定改服务是否执行启动还是继续等待，从而实现应用中的服务依照依赖关系顺序启动。但是其设计的主要缺点是额外引入初始化容器，增加复杂性。在一个服务中使用多个初始化容器描述服务之间的依赖关系，使用图形化方式编排生成或解析展示这类应用模版比较困难。在运行时管理上，是通过初始化容器等待实现依赖关系的处理，本质是还是将应用的所有服务相关的资源一次性下发给kubernetes，只是在初始化容器中等待依赖服务就绪，应用运行时的拓扑结构展示不够友好。而且引入了初始化容器，对描述结构增加复杂性，资源描述文件和图形化转换较为困难，难以实现应用的图形化编排，应用运行时的拓扑结构展示不够友好。

需要说明的是，原生kubernetes不支持服务间依赖关系的处理，helm模版虽然实现了服务资源的模版化管理，但也不支持服务间依赖关系的处理，都是直接将应用下所有服务相关的资源一次性下发至kubernetes，但由于服务启动顺序的关系，会导致某些服务因为依赖的服务未就绪而启动失败。而且由于没有依赖关系描述，无法将运行时应用实例的拓扑结构进行图形化展示，不方便对应用的运行时状态进行管理，无法实现应用的自动化部署运维。

本发明可选实施例提出了一种基于kubernetes的应用编排部署方案，使用了层级依赖结构来描述应用中服务的依赖关系，极大的简化了依赖关系描述的数据结构，使图形化转换为模版文件描述，模版文件解析为图形化，容易实现应用的图形化编排。对于运行时管理，根据依赖关系顺序部署的处理逻辑也变得相对简单，可以方便得实现运行时应用实例拓扑结构的图形化展示。使得对于复杂的应用，能够快速实现应用定义和部署，能够进行应用的模版化管理，模版的图形化编排，部署时支持运行时依赖关系的处理，使复杂应用能够被自动化部署运维。

可选的，为了方便应用的资源管理，同时也为了方便多环境的应用复制，就需要将应用的资源模版化，图3为本发明可选实施例的服务模版的结构示意图；通过应用模版将资源合理的组织，实现资源的高效管理和应用的快速部署。具体的，应用模版定义由模版元数据，服务模版列表，配置输入参数列表，输出参数列表组成。配置输入参数是将应用中常变的值以变量的形式替代，在部署时，通过应用模版+配置项的组合，方便用户部署相应应用到不同的环境。服务模版是应用模版的基本组成部分，是应用编排的基本组件，服务模版的定义由模版元数据，资源列表，配置输入参数列表，输出参数列表组成，服务模版是对服务相关资源的集中管理。

进一步的，服务模版将服务相关的工作负载资源deployment或statefulset的yaml描述文件和配置资源volume，secret，configmap，service的yaml描述文件封装为一个文件集合，并定义服务模版的元数据，将服务中常变的值以变量的形式替代，定义为配置输入参数，在部署时由程序将配置项传入输入参数，完成服务模版渲染。输出参数是服务运行时生成的变量，主要为服务的域名或pod的ip，这些变量可作为下级依赖服务的输入参数。服务模版通过对资源的封装定义，实现相对独立的管理，作为应用模版编排的基本组件，可以方便的实现通过拖拽的方式进行图形化编排。

作为一种可选的实施例，为了实现服务依赖关系的描述，并使描述的结构尽量简单，从而使应用模版图形化的拓扑解析和生成简化，设计了一种层级依赖的结构。如图4所示，为本发明可选实施例的层级依赖的结构示意图。层级依赖结构主要是将服务模版列表按依赖关系深度进行分层，相同依赖深度的服务模版放在同一层，相当于上一层的服务模版依赖下一层的服务模版。这样只需要对应用模版中每个服务模版标注所属层级即可实现依赖关系的描述。对于服务模版输入输出关系的描述，只需要在服务模版输入参数变量中关联下层被依赖服务的输出参数变量，但在拓扑结构中并不使用输入输出的依赖关系。这样虽然在应用模版的拓扑结构中没有建立具体服务之间的依赖关系，但在部署时，会根据服务模版的层级，按层级顺序进行服务的资源下发kubernetes，当同一层级的服务就绪后，再部署下一层级服务，由于此时本层服务依赖的服务已经就绪，启动时就不会异常。因此仍然能够实现服务的顺序部署。另外应用模版支持子应用模版的嵌套，即将已经编排好的其他应用模版，作为应用模版的组件编排进来，输入输出关系同服务模版一致。

作为一种可选的实施例，应用模版编排完成后存储于应用商店中，在运行时管理中，实现对部署应用模版的依赖关系处理。如图5所示，为本发明可选实施例的应用部署方法的流程图，具体内容如下：

步骤1：当用户输入应用配置项参数，选装应用模版进行部署时，运行时管理模块根据应用模版名称和版本号，从应用商店(相当于本发明实施例中的目标数据库)查询应用模版文件，解析应用模版描述信息。

步骤2：从商店查询应用模版文件查询到应用模版文件的情况下，获取应用模版中服务模版层级信息(即确定应用模版中每一个模版元素的层级信息)，根据层级信息，首先获取第0层所有服务模版，第0层服务不依赖其他服务，需要最先启动。

步骤3：并发部署第i层所有模板，开启异步线程开始部署该层级所有服务。

步骤4：根据模版元数据信息描述，判断模版是服务模版还是子应用模版，如果是子应用模版，进行递归调用，进行子应用模版的部署，等待子应用部署完成后，继续后面的流程。为保证部署性能，限制子应用模版嵌套层级为1。如果是服务模版，进行服务模版的部署。

步骤5：加载服务模版资源文件，从服务模版输入参数描述中，解析输入输出关系描述，服务模版输入参数来源包括：1)前面层级中依赖服务的输出参数，通过service.${serviceName}.output.{param}描述引用。2)前面层级中依赖子应用的输出参数通过subapp.${appName}.output.{param}描述引用。3)部署应用时输入的应用配置项输入参数，通过app.input.${param}。

可选的，在解析输入输出关系时，根据引用描述中服务名或子应用名，查找前面层级中已部署的服务实例或应用实例，再根据参数名，从输出参数中匹配到具体值，如果引用描述是应用配置项输入参数，就根据参数名直接从配置项输入参数中匹配具体值，获取该值(即输入参数变量值)后，作为服务模版的输入参数，替换服务模版中yaml资源文件中的变量占位符，完成yaml资源文件的渲染。

步骤6：将渲染后的kubernetes yaml资源对象下发至kubernetes，优先创建volume(对象)，secret(敏感信息配置信息)，configmap(配置图)等配置资源，再创建deployment(调度)或statefulset(有状态集)等工作负载资源。

步骤7：本层级所有服务完成资源创建后，监听kubernetes关于本层级所有服务的工作负载就绪(Ready)事件，当某个服务的就绪事件上报后，就更新应用实例中该服务实例的状态为上线就绪，并判断本层级所有服务是否都已就绪，如果还未就绪，继续监听。

步骤8：本层级所有服务状态就绪后，进行下一层服务模版的部署，循环这一过程，直到所有层级部署完成。

步骤9：所有层级部署完成后，修改应用状态为上线就绪，整个部署流程结束。

综上，通过上述流程，实现了应用运行时管理，部署服务依赖关系的处理，保证了应用中服务的启动顺序，提供简单的，直观的图形化应用实例拓扑结构展示，方便进行整个应用状态和各服务状态的管理，可以快速识别应为哪个服务的失败导致应用部署的失败，实现应用的自动化部署运维。

通过上述实施例，提出了一种相对简单的方式描述应用中服务之间的依赖关系，能够实现应用模版通过组件拖拽方式进行应用模版的编排，解决复杂应用管理kubernetes资源的复杂性问题，简化用户编排yaml配置文件操作。在运行时管理上，根据服务依赖关系，有序将服务资源下发到kubernetes中，避免因为服务启动顺序问题导致服务启动失败。并通过图形化展示应用实例拓扑视图，是应用部署更加直观，能够快速定位因为依赖关系中哪个服务失败导致整个应用启动失败，使用户更好地了解应用实例的状态，并且通过一种应用编排的方法，通过层级依赖的结构描述应用中服务的依赖关系，实现应用的图形化编排；层级依赖是按服务具体的依赖关系中的依赖深度进行分层，相同依赖深度的服务都归入统一层级，解析过程中去除了对服务具体依赖关系的处理。利用层级依赖进行应用模版的部署，通过解析应用模版中的层级依赖，按顺序完成服务的部署。以及基于层级依赖应用实例的运行时管理，图形化展示应用运行时的拓扑结构，使得应用场景更广泛。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

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

根据本发明实施例的另一个方面，还提供了一种用于实施上述配置文件的确定方法的配置文件的确定装置。如图6所示，该装置包括：

获取模块62，用于获取目标应用的配置项参数，并根据所述配置项参数在目标数据库中进行查询，得到所述目标应用的应用模版文件；

解析模块64，用于解析所述应用模版文件，得到所述应用模版文件包括的多个子模版和每一个子模版的层级信息，其中，所述每一个子模版；

部署模块66，用于依据所述每一个子模版的层级信息，对所述多个子模版中每一个子模版进行逐层部署，并对部署完成的所述每一个子模版加载对应的资源文件；

确定模块68，用于根据所述资源文件在所述每一个子模版中的加载信息确定用于运维所述目标应用的配置文件。

通过上述装置，获取目标应用的配置项参数，并根据配置项参数在目标数据库中进行查询，得到目标应用的应用模版文件；解析应用模版文件，得到应用模版文件包括的多个子模版和每一个子模版的层级信息，其中，每一个子模版的层级信息用于指示每一个子模版在应用模版文件中的层级；依据每一个子模版的层级信息，对多个子模版中每一个子模版进行逐层部署，并对部署完成的每一个子模版加载对应的资源文件；根据资源文件在每一个子模版中的加载信息确定用于运维目标应用的配置文件，即使用了层级依赖结构来描述应用中服务的依赖关系，极大的简化了依赖关系描述的数据结构，使得部署目标应用的处理逻辑也变得相对简单，可以方便得实现运行时目标应用的实例拓扑结构的图形化展示，进而达到了对复杂的目标应用进行资源编排的目的，从而实现了对目标应用进行有效且快速的自动化部署运维的技术效果，进而解决了现有技术中无法对复杂应用进行资源编排，并对应用资源进行有序部署的技术问题。

需要说明的是，上述子模版以及应用模版文件可以显示为图形化编排，通过拖拽的方式进行拓扑视图的展示，继而当应用模版文件中的一个子模版出现问题后，可以快速查找到对应的启用失败的子模版，使得用户在部署目标应用时能够更加直观，能够快速定位依据层级间的依赖关系进行应用上线前的编排测试。

在一个示例性实施例中，上述装置还包括：类型模块，用于获取所述每一个子模版对应的元数据的信息描述；根据所述每一个子模版对应的元数据的信息描述，确定所述每一个子模版的属性，其中，所述每一个子模版的属性用于指示所述每一个子模版的模版类型，所述每一个子模版的模版类型用于确定所述每一个子模版对应的资源文件的加载方式。

在一个示例性实施例中，上述类型模块，还用于在所述多个子模版包括第一组子模版、且所述第一组子模版中的每一个子模版的属性指示的模版类型为服务模版的情况下，确定所述第一组子模版中的每一个子模版对应的逐层部署方式为直接部署；在所述多个子模版包括第二组子模版、且所述第二组子模版中的每一个子模版的属性指示的模版类型为子应用模版的情况下，确定所述第二组子模版中的每一个子模版对应的逐层部署方式为调用部署，其中，所述调用部署用于指示对已经编排好的其他应用通过嵌套方式进行递归调用。

简而言之，由于子模版的类型不同，在部署时需要的部署方式也不同，故需要根据模版元数据信息描述，判断子模版是服务模版还是子应用模版，如果是子应用模版，进行递归调用(即将已经编排好的其他应用模版，作为应用模版的组件编排进当前目标应用的模版中)，进行子应用模版的部署，等待子应用部署完成后，继续后面的流程。为保证部署性能，限制子应用模版嵌套层级为1。如果是服务模版，直接进行服务模版的部署。

可选的，上述部署模块，还用于根据所述每一个子模版的层级信息，对所述多个子模版进行层级分类，得到多个子模版集合，其中，所述多个子模版中层级相同的子模版被分类成一个子模版集合，所述多个子模版集合中的每个子模版集合对应一个层级；从最小层级对应的子模版集合开始，根据层级顺序逐层部署不同层级对应的子模版集合，并在所述子模版集合部署完成后加载所述子模版集合中的子模版对应的资源文件。

可以理解的是，在对多个子模版进行部署以及对应资源文件的加载时，需要根据层级进行一层一层的加载，以保证不同层级之间的依赖关系，使得相关联的目标应用的功能之间建立对应的联系，明确了上一层的服务模版与下一层的服务模版的依赖关系。

在一个示例性实施例中，上述确定模块，还用于在所述目标应用的配置项参数不包括输入参数的情况下，获取所述每一个子模版的加载信息对应的参数描述信息，并根据所述参数描述信息确定所述每一个子模版的输入参数变量值；通过所述输入参数变量值替换所述每一个子模版的变量占位符，得到用于运维所述目标应用的所述配置文件；或者在所述目标应用的配置项参数包括输入参数的情况下，确定所述配置项参数中的输入参数名，将所述输入参数名在预设的参数库中进行匹配，得到所述配置项参数对应的目标输入参数变量值；通过所述目标输入参数变量值替换所述每一个子模版的变量占位符，得到用于运维所述目标应用的所述配置文件。

在一个示例性实施例中，上述确定模块，还用于在所述参数描述信息中携带的输入输出关系，且所述每一个子模版不属与最小层级的情况下，获取所述每一个子模版的引用描述；其中，所述引用描述中包括：加载的所述资源文件中包含的参数名和当前所述每一个子模版所在层级之前其他层级加载资源文件后每一个子模版的输出参数；确定所述其他层级加载资源文件后每一个子模版的输出参数对应的目标参数名与所述资源文件中包含的参数名匹配结果；在所述匹配结果指示所述资源文件中包含的参数名存在匹配的所述输出参数的情况下，将所述输出参数的具体参数值作为所述每一个子模版的输入参数变量值。

可选的，加载子模版的资源文件，从子模版输入参数描述中，解析输入输出关系描述，子模版输入参数来源包括：1)前面层级中依赖服务的输出参数，通过service.${serviceName}.output.{param}描述引用。2)前面层级中依赖子应用的输出参数通过subapp.${appName}.output.{param}描述引用。3)部署应用时输入的应用配置项输入参数，通过app.input.${param}。

可选的，在解析输入输出关系时，根据引用描述中服务名或子应用名，查找前面层级中已部署的服务实例或应用实例，再根据参数名，从输出参数中匹配到具体值，如果引用描述是应用配置项输入参数，就根据参数名直接从配置项输入参数中匹配具体值，获取该值(即输入参数变量值)后，作为子模版的输入参数，替换子模版中yaml资源文件(相当于本发明实施例中的配置文件)中的变量占位符，完成yaml资源文件的渲染。

在一个示例性实施例中，上述装置还包括：上线模块，用于将所述配置文件发送至容器编排平台，并监听所述容器编排平台根据所述配置文件创建的工作负载就绪事件；其中，所述工作负载就绪事件用于确定所述目标应用对应功能的状态为上线状态；确定所述应用模版文件对应的所述工作负载就绪事件的创建数量；在所述创建数量大于所述多个子模版的个数的情况下，确定所述目标应用完成上线就绪。

例如，将渲染后的kubernetes yaml资源对象下发至容器编排平台kubernetes，优先创建volume(对象)，secret(敏感信息配置信息)，configmap(配置图)等配置资源，再创建deployment(调度)或statefulset(有状态集)等工作负载资源。本层级所有服务完成资源创建后，监听kubernetes关于本层级所有服务的工作负载就绪(Ready)事件，当某个服务的就绪事件上报后，就更新应用实例中该服务实例的状态为上线就绪，并判断本层级所有服务是否都已就绪，如果还未就绪，继续监听。本层级所有服务状态就绪后，进行下一层子模版的部署，循环这一过程，直到所有层级部署完成。所有层级部署完成后，修改应用状态为上线就绪，整个部署流程结束。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

本发明的实施例还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的计算机程序：

S1、获取目标应用的配置项参数，并根据所述配置项参数在目标数据库中进行查询，得到所述目标应用的应用模版文件；

S2、解析所述应用模版文件，得到所述应用模版文件包括的多个子模版和每一个子模版的层级信息，其中，所述每一个子模版的层级信息用于指示所述每一个子模版在所述应用模版文件中的层级；

S3、依据所述每一个子模版的层级信息，对所述多个子模版中每一个子模版进行逐层部署，并对部署完成的所述每一个子模版加载对应的资源文件；

S4、根据所述资源文件在所述每一个子模版中的加载信息确定用于运维所述目标应用的配置文件。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

本发明的实施例还提供了一种电子设备，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子设备还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

S1、获取目标应用的配置项参数，并根据所述配置项参数在目标数据库中进行查询，得到所述目标应用的应用模版文件；

S2、解析所述应用模版文件，得到所述应用模版文件包括的多个子模版和每一个子模版的层级信息，其中，所述每一个子模版的层级信息用于指示所述每一个子模版在所述应用模版文件中的层级；

S3、依据所述每一个子模版的层级信息，对所述多个子模版中每一个子模版进行逐层部署，并对部署完成的所述每一个子模版加载对应的资源文件；

S4、根据所述资源文件在所述每一个子模版中的加载信息确定用于运维所述目标应用的配置文件。

可选地，在本实施例中，本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(Random Access Memory，RAM)、磁盘或光盘等。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种配置文件的确定方法，其特征在于，包括：

获取目标应用的配置项参数，并根据所述配置项参数在目标数据库中进行查询，得到所述目标应用的应用模版文件；

解析所述应用模版文件，得到所述应用模版文件包括的多个子模版和每一个子模版的层级信息，其中，所述每一个子模版的层级信息用于指示所述每一个子模版在所述应用模版文件中的层级；

依据所述每一个子模版的层级信息，对所述多个子模版中每一个子模版进行逐层部署，并对部署完成的所述每一个子模版加载对应的资源文件；

根据所述资源文件在所述每一个子模版中的加载信息确定用于运维所述目标应用的配置文件。

2.根据权利要求1所述的方法，其特征在于，所述解析所述应用模版文件，得到所述应用模版文件包括的多个子模版和每一个子模版的层级信息之后，所述方法还包括：

获取所述每一个子模版对应的元数据的信息描述；

根据所述每一个子模版对应的元数据的信息描述，确定所述每一个子模版的属性，其中，所述每一个子模版的属性用于指示所述每一个子模版的模版类型，所述每一个子模版的模版类型用于确定所述每一个子模版对应的资源文件的加载方式。

3.根据权利要求2所述的方法，其特征在于，所述根据所述每一个子模版对应的元数据的信息描述，确定所述每一个子模版的属性，包括：

在所述多个子模版包括第一组子模版、且所述第一组子模版中的每一个子模版的属性指示的模版类型为服务模版的情况下，确定所述第一组子模版中的每一个子模版对应的逐层部署方式为直接部署；

在所述多个子模版包括第二组子模版、且所述第二组子模版中的每一个子模版的属性指示的模版类型为子应用模版的情况下，确定所述第二组子模版中的每一个子模版对应的逐层部署方式为调用部署，其中，所述调用部署用于指示对已经编排好的其他应用通过嵌套方式进行递归调用。

4.根据权利要求1所述的方法，其特征在于，依据所述每一个子模版的层级信息，对所述多个子模版中每一个子模版进行逐层部署，并对部署完成的所述每一个子模版加载对应的资源文件，包括：

根据所述每一个子模版的层级信息，对所述多个子模版进行层级分类，得到多个子模版集合，其中，所述多个子模版中层级相同的子模版被分类成一个子模版集合，所述多个子模版集合中的每个子模版集合对应一个层级；

从最小层级对应的子模版集合开始，根据层级顺序逐层部署不同层级对应的子模版集合，并在所述子模版集合部署完成后加载所述子模版集合中的子模版对应的资源文件。

5.根据权利要求1所述的方法，其特征在于，根据所述资源文件在所述每一个子模版中的加载信息确定用于运维所述目标应用的配置文件，包括：

在所述目标应用的配置项参数不包括输入参数的情况下，获取所述每一个子模版的加载信息对应的参数描述信息，并根据所述参数描述信息确定所述每一个子模版的输入参数变量值；通过所述输入参数变量值替换所述每一个子模版的变量占位符，得到用于运维所述目标应用的所述配置文件；或者

在所述目标应用的配置项参数包括输入参数的情况下，确定所述配置项参数中的输入参数名，将所述输入参数名在预设的参数库中进行匹配，得到所述配置项参数对应的目标输入参数变量值；

通过所述目标输入参数变量值替换所述每一个子模版的变量占位符，得到用于运维所述目标应用的所述配置文件。

6.根据权利要求5所述的方法，其特征在于，根据所述参数描述信息确定所述每一个子模版的输入参数变量值，包括：

在所述参数描述信息中携带的输入输出关系，且所述每一个子模版不属与最小层级的情况下，获取所述每一个子模版的引用描述；其中，所述引用描述中包括：加载的所述资源文件中包含的参数名和当前所述每一个子模版所在层级之前其他层级加载资源文件后每一个子模版的输出参数；

确定所述其他层级加载资源文件后每一个子模版的输出参数对应的目标参数名与所述资源文件中包含的参数名匹配结果；

在所述匹配结果指示所述资源文件中包含的参数名存在匹配的所述输出参数的情况下，将所述输出参数的具体参数值作为所述每一个子模版的输入参数变量值。

7.根据权利要求1所述的方法，其特征在于，在根据所述资源文件在所述每一个子模版中的加载信息确定用于运维所述目标应用的配置文件之后，所述方法还包括：

将所述配置文件发送至容器编排平台，并监听所述容器编排平台根据所述配置文件创建的工作负载就绪事件；其中，所述工作负载就绪事件用于确定所述目标应用对应功能的状态为上线状态；

确定所述应用模版文件对应的所述工作负载就绪事件的创建数量；

在所述创建数量大于所述多个子模版的个数的情况下，确定所述目标应用完成上线就绪。

8.一种配置文件的确定装置，其特征在于，包括：

获取模块，用于获取目标应用的配置项参数，并根据所述配置项参数在目标数据库中进行查询，得到所述目标应用的应用模版文件；

解析模块，用于解析所述应用模版文件，得到所述应用模版文件包括的多个子模版和每一个子模版的层级信息，其中，所述每一个子模版；

部署模块，用于依据所述每一个子模版的层级信息，对所述多个子模版中每一个子模版进行逐层部署，并对部署完成的所述每一个子模版加载对应的资源文件；

确定模块，用于根据所述资源文件在所述每一个子模版中的加载信息确定用于运维所述目标应用的配置文件。

9.一种计算机可读的存储介质，其特征在于，所述计算机可读的存储介质包括存储的程序，其中，所述程序运行时执行所述权利要求1至7任一项中所述的方法。

10.一种电子设备，包括存储器和处理器，其特征在于，所述存储器中存储有计算机程序，所述处理器被设置为通过所述计算机程序执行所述权利要求1至7任一项中所述的方法。

Images