一种可视化应用组件编排方法及系统与流程

本发明涉及计算机软件技术领域，具体涉及一种可视化应用组件编排方法及系统。

背景技术：

如图1所示，现有的kubernetes编排通常是通过yaml格式或json格式的配置文件来部署应用，通过调用apiserver提供的接口创建pod(plainolddatastructure)、service资源。

在通过kubernetes部署应用时，通常需要针对应用编写pod、service配置文件,针对不常使用的人来说不易理解记住参数的具体含义，需要部署人员对配置参数做到熟记于心，而经常使用的人又抱怨每次在部署时都要编写繁琐重复的配置文件，并且通过复杂的配置来部署一个应用时配置文件往往容易出现疏漏，不易排查部署失败的问题。部署人员需手动编写配置文件的每一行代码，同时需要确保格式的正确，当构建复杂应用时，还需要查阅相关参数文档，费时费力。上述问题亟待解决，为此，提出一种可视化应用组件编排方法及系统。

技术实现要素：

本发明所要解决的技术问题在于：如何解决现有技术中通过kubernetes部署应用时存在的配置文件编写过程繁琐、容易出现疏漏、不易排查部署失败等问题，提供了一种可视化应用组件编排方法。

本发明是通过以下技术方案解决上述技术问题的，本发明包括以下步骤：

s1：可视化配置

根据部署应用所需的基础应用、中间件，通过可视化操作形式配置基础应用间逻辑调用关系及基础应用的依赖关系，生成相应的拓扑图；

s2：参数校验

对步骤s1中配置的参数进行校验；

s3：参数转换

将可视化配置生成的拓扑图通过参数转换引擎转换为符合json或yaml格式的配置文件；

s4：部署应用

根据经参数转换后的配置文件进行部署，集群根据配置文件通过apiserver创建相应的资源，完成应用的部署。

更进一步的，在所述步骤s1中，可视化操作形式为在本系统平台上提供的可视化界面进行的连线、拖拽形式。

更进一步的，在所述步骤s1中，进行可视化操作的同时即完成了参数的配置工作，配置基础应用的依赖关系即配置基础应用所依赖的服务、组件等。

更进一步的，在所述步骤s2中，对步骤s1中配置的参数进行校验的方式为将配置的参数与官方配置预定义的参数以及具有特定参数值的参数进行比对，校验步骤s1中配置的参数值是否正确。

更进一步的，当参数校验失败后，则不进入所述步骤s3中，并将参数校验失败的信息写入日志，其中参数校验失败信息主要包括输入的参数值不在设定的范围内、预定义参数不符合命名规范(如以纯数字命名参数)、输入的参数值类型不匹配等信息；当参数校验成功后，则进入所述步骤s3中，对配置完成的参数进行转换。

更进一步的，在所述步骤s3中，利用参数转换引擎进行转换的过程为将用户填写的配置参数与配置文件模板里的参数逐个比较(其中配置文件模板是系统平台中预先定义好的，对用户来说是透明的)，然后将配置文件模板里的预定义参数值替换成用户填写的参数值(例如用户定义参数a的值为a,在模板中查找对应参数为a并用a替换掉模板中的值)，配置文件模板中的参数值全部替换完成后即完成参数转换。根据配置文件模板和不同的参数值生成不同内容的配置文件，使模板更具通用性。

更进一步的，当参数转换失败后，则不进入所述步骤s4中，并将参数转换失败的信息写入日志，其中参数转换失败信息主要包括转换异常的参数名称、参数值、异常堆栈信息、参数所属组件、参数所属编排等；当参数转换成功后，则进入所述步骤s4中，完成应用的部署。

更进一步的，在所述步骤s4中，相应的资源为pod、service等。

更进一步的，部署过程完成后，会将当前应用部署过程产生的日志持久化，部署日志包括部署状态、部署时间、部署应用名称、失败堆栈信息、成功后应用访问地址等，日志信息存储在mysql数据库表中，方便用户在部署失败后查看相应的部署日志排查问题。

更进一步的，无论部署过程是成功或失败，均将部署结果反馈给用户，以便用户对下一步做出判断。当部署失败，将失败日志反馈；成功时将部署成功后的应用的访问方式反馈给用户。用户每次部署都会在系统平台上生成一条部署日志记录保存到数据库中，并提供页面供用户进行部署日志的查看，部署失败的日志展示失败堆栈信息，部署成功的日志展示应用的访问地址。

本发明还提供了一种可视化应用组件编排系统，包括：

可视化配置模块，用于根据部署应用所需的基础应用、中间件，通过可视化操作形式配置基础应用间逻辑调用关系及基础应用的依赖关系，生成相应的拓扑图；

参数校验模块，用于对配置完的参数进行校验；

参数转换模块，用于将可视化配置生成的拓扑图通过参数转换引擎转换为符合json或yaml格式的配置文件；

应用部署模块，用于根据经参数转换后的配置文件进行部署，集群根据配置文件通过apiserver创建相应的资源，完成应用的部署；

控制处理模块，用于向其他模块发出指令，完成相关动作；

所述可视化配置模块、参数校验模块、参数转换模块、应用部署模块均与控制处理模块建立连接。

本发明相比现有技术具有以下优点：该可视化应用组件编排方法，通过可视化方式编排应用组件，可以减少部署人员的工作量和失误率，提高效率，部署人员不用考虑部署的配置文件格式，参数转换引擎会根据用户需求自动生成相应的json或yaml格式的配置文件，由于参数配置使用界面化的形式，提升了用户体验，降低了新手的使用难度，值得被推广使用。

附图说明

图1是现有技术中应用组件编排方法的系统结构示意图；

图2是本发明实施例一中可视化应用组件编排方法的总体流程示意图；

图3是本发明实施例二中可视化应用组件编排方法的系统结构示意图；

图4是本发明实施例三中可视化应用组件编排方法的实施流程示意图；

图5是本发明实施例四中步骤1的操作界面图；

图6是本发明实施例四中步骤2的操作界面图；

图7是本发明实施例四中步骤3的操作界面图；

图8是本发明实施例四中步骤4的操作界面图。

具体实施方式

下面对本发明的实施例作详细说明，本实施例在以本发明技术方案为前提下进行实施，给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。

实施例一

如图2所示，本实施例提供一种技术方案：一种可视化应用组件编排方法，包括以下步骤：

s1：可视化配置

根据部署应用所需的基础应用、中间件，通过可视化操作形式配置基础应用间逻辑调用关系及基础应用的依赖关系，生成相应的拓扑图；

s2：参数校验

对步骤s1中配置的参数进行校验；

s3：参数转换

将可视化配置生成的拓扑图通过参数转换引擎转换为符合json或yaml格式的配置文件；

s4：部署应用

根据经参数转换后的配置文件进行部署，集群根据配置文件通过apiserver创建相应的资源，完成应用的部署。

在所述步骤s1中，可视化操作形式为在本系统平台上提供的可视化界面进行的连线、拖拽形式。

在所述步骤s1中，进行可视化操作的同时即完成了参数的配置工作，配置基础应用的依赖关系即配置基础应用所依赖的服务、组件等。

在所述步骤s2中，对步骤s1中配置的参数进行校验的方式为将配置的参数与官方配置预定义的参数以及具有特定参数值的参数进行比对，校验步骤s1中配置的参数值是否正确。

当参数校验失败后，则不进入所述步骤s3中，并将参数校验失败的信息写入日志，其中参数校验失败信息主要包括输入的参数值不在设定的范围内、预定义参数不符合命名规范(如以纯数字命名参数)、输入的参数值类型不匹配等信息；当参数校验成功后，则进入所述步骤s3中，对配置完成的参数进行转换。

在所述步骤s3中，利用参数转换引擎进行转换的过程为将用户填写的配置参数与配置文件模板里的参数逐个比较(其中配置文件模板是系统平台中预先定义好的，对用户来说是透明的)，然后将配置文件模板里的预定义参数值替换成用户填写的参数值(例如用户定义参数a的值为a,在模板中查找对应参数为a并用a替换掉模板中的值)，配置文件模板中的参数值全部替换完成后即完成参数转换。根据配置文件模板和不同的参数值生成不同内容的配置文件，使模板更具通用性。

当参数转换失败后，则不进入所述步骤s4中，并将参数转换失败的信息写入日志，其中参数转换失败信息主要包括转换异常的参数名称、参数值、异常堆栈信息、参数所属组件、参数所属编排等信息；当参数转换成功后，则进入所述步骤s4中，完成应用的部署。

在所述步骤s4中，相应的资源为pod、service等。

部署过程完成后，会将当前应用部署过程产生的日志持久化，部署日志包括部署状态、部署时间、部署应用名称、失败堆栈信息、成功后应用访问地址等信息，日志信息存储在mysql数据库表中，方便用户在部署失败后查看相应的部署日志排查问题。

无论部署过程是成功或失败，均将部署结果反馈给用户，以便用户对下一步做出判断。当部署失败，将失败日志反馈；成功时将部署成功后的应用的访问方式反馈给用户。用户每次部署都会在系统平台上生成一条部署日志记录保存到数据库中，并提供页面供用户进行部署日志的查看，部署失败的日志展示失败堆栈信息，部署成功的日志展示应用的访问地址。

本实施例还提供了一种可视化应用组件编排系统，包括：

可视化配置模块，用于根据部署应用所需的基础应用、中间件，通过可视化操作形式配置基础应用间逻辑调用关系及基础应用的依赖关系，生成相应的拓扑图；

参数校验模块，用于对配置完的参数进行校验；

参数转换模块，用于将可视化配置生成的拓扑图通过参数转换引擎转换为符合json或yaml格式的配置文件；

应用部署模块，用于根据经参数转换后的配置文件进行部署，集群根据配置文件通过apiserver创建相应的资源，完成应用的部署；

控制处理模块，用于向其他模块发出指令，完成相关动作；

所述可视化配置模块、参数校验模块、参数转换模块、应用部署模块均与控制处理模块建立连接。

实施例二

如图3所示，为本实施例中基于可视化应用组件编排方法的系统结构示意图；图中的各部分说明如下：

1)、用户：

使用kubernetes部署应用的部署人员。

2)、图形化界面：

本系统平台提供可视化设计页面，通过在图形化界面连线、拖拽方式配置参数之间的依赖关系完成原本需要手动编写配置文件的任务；主要通过jsplumb、jquery、jqueryui等技术控制前端样式的展现包括组件的拖动，组件之间的连线，组件及连线的点击触发事件处理。

3)、参数校验：

参数校验主要用于和kubernetes官方配置预定义的参数以及一些有特定参数值的参数进行比对，校验用户填写的参数值是否正确，在部署之前及时发现并纠错，降低出错率。

4)、参数转换引擎：

在连线、拖拽方式的配置过程完成后，此时对用户来说能看到的配置文件是一幅拓扑图，拓扑图对用户来说易于理解表示逻辑关系，对部署的机器来说需要将其转换为对应格式的配置文件，kubernetes集群才能部署应用。参数转换引擎将用户的图形化配置，按照部署程序自动转换为yaml或json格式的配置文件，参数转换引擎将用户填写的配置参数与配置文件模板里的参数逐个比较(其中配置文件模板是系统平台中预先定义好的，对用户来说是透明的)，然后将配置文件模板里的预定义参数值替换成用户填写的参数值(例如用户定义参数a的值为a,在模板中查找对应参数为a并用a替换掉模板中的值)，配置文件模板中的参数值全部替换完成后即完成参数转换。根据配置文件模板和不同的参数值生成不同内容的配置文件，使模板更具通用性。

5)、apiserver：

在部署应用时并不直接操作kubernetes集群机器，而是以api形式访问kubernetes集群，以api的形式访问可以确保接口统一，同时apiserver也包含了授权控制机制，可以保障kubernetes集群机器的安全，其中授权控制是kubernetes自身的特性，类似多租户的隔离。

6)、kubernetes集群：

提前部署在用于部署应用的虚拟机或物理机中，用于将参数转换引擎生成的yaml或json格式的配置文件部署成可运行的应用。

实施例三

本实施例提供了一种可视化应用组件编排方法，通过界面化的参数配置，降低了用户认知成本和使用难度，同时减少了配置参数的出错率并提高用户部署应用的效率，提升了用户体验。

如图4所示，为该可视化应用组件编排方法的具体执行流程示意图。

该可视化应用组件编排方法主要包括以下步骤：

第一步：用户可视化配置

用户根据自身部署应用所需要的基础应用、中间件，通过连线、拖拽方式配置基础应用之间的逻辑调用关系，配置基础应用所依赖的服务、组件等，生成相应的拓扑图；

第二步：参数校验

在部署应用之前，对用户配置的参数进行校验，校验的方式是将用户配置的参数和kubernetes官方配置预定义的参数以及一些有特定参数值的参数进行比对，校验用户填写的参数值是否正确，通过用户定义的参数和预定义的参数集合进行逐一比较，预定义集合包含当前kubernetes的所有参数，是系统平台预定义的，对用户是透明的；当参数校验失败后，则不进入下一步的参数转化步骤中，并将参数校验失败的信息写入日志，其中参数校验失败信息主要包括输入的参数值不在设定的范围内、预定义参数不符合命名规范(如以纯数字命名参数)、输入的参数值类型不匹配等信息，实现参数校验步骤的反馈工作，参数校验成功后，方可进入下一步的参数转化步骤中，对配置完成的参数进行转换；

第三步：参数转换

将可视化配置生成的拓扑图按照参数转换引擎自动转换为符合json或yaml格式的配置文件，参数转换引擎就是依次遍历所有组件，针对每个组件根据用户填写的参数值不断查找替换，可以理解模板是一个集合，用户填写的参数是模板集合的子集，转换就是不断查找子集和父集的共同参数并以子集的参数值替换父集的参数值的过程，这里参数转换对用户来说是透明的，用户察觉不到；在参数转换失败后，则不进入下一步的部署应用步骤中，并将参数转换失败的信息写入日志，其中参数转换失败信息主要包括转换异常的参数名称、参数值、异常堆栈信息、参数所属组件、参数所属编排等信息，参数转换成功后，方可进入下一步的部署应用步骤中以完成应用的部署；

第四步：部署应用

经过参数转换步骤后，根据转换后符合json或yaml格式的配置文件进行部署，kubernetes集群根据配置文件通过apiserver创建相应的资源如pod、service，至此便完成了应用的部署；

第五步：生成部署日志

部署过程完成后，会将当前应用部署过程产生的日志持久化，部署日志包括部署状态、部署时间、部署应用名称、失败堆栈信息、成功后应用访问地址等信息，日志信息存储在mysql数据库表中，方便用户在部署失败后查看相应的部署日志排查问题；

第六步：日志反馈

无论部署是成功或失败，需要将部署的结果反馈给用户，以便用户对下一步做出判断。当部署失败，将失败日志反馈给用户。用户每次部署都会在系统平台上生成一条部署日志记录保存到数据库中，并提供页面供用户进行部署日志的查看，部署失败的日志展示失败堆栈信息，部署成功的日志展示应用的访问地址。

实施例四

如图5～8所示，本实施例提出了一种可视化应用组件编排方法，该可视化应用组件编排方法具体包括如下步骤：

步骤1：用户通过拖拽、连线的形式配置部署应用的参数

具体实现过程如下：

根据用户的应用部署需求，将本系统平台上提供的应用组件(图5中左侧的tab栏)根据部署的应用是否需要该基础组件(如mysql、nginx等)拖动相应的应用组件到设计栏，通过连线配置组件间的调用关系以及组件参数值，如图5所示。

步骤2：配置组件预定义的参数

通过填写预定义参数，配置各组件相关参数值，如图6所示。

步骤3：配置组件间参数调用关系

当部署应用涉及到多个组件时并且一个组件依赖于另一个组件，配置组件间参数的调用关系，如图7所示。

步骤4：参数转换为配置文件

用户完成组件的设计后，会将配置的参数转换为一个配置文件，如图8所示。

综上所述，上述各实施例的可视化应用组件编排方法，相比传统通过手动编写配置部署文件，需要牢记kubernetes预定义的参数，通过可视化方式编排应用组件，可以减少部署人员的工作量和失误率，提高效率，部署人员不用考虑部署的配置文件格式，参数转换引擎会根据用户需求自动生成相应的json或yaml格式的配置文件，由于参数配置使用界面化的形式，提升了用户体验，降低了新手的使用难度，值得被推广使用。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。