配置文件的生成方法及应用部署方法

技术领域

本申请涉及容器云技术领域，特别是涉及一种配置文件的生成方法及应用部署方法。

背景技术

在容器云平台上部署应用的过程通常包括：先将服务产品制作成chart包，然后利用Helm渲染器进行chart包部署和管理，实现在容器云平台上部署应用。

本申请的发明人发现，现有技术在对chart包中的配置项进行修改编辑后生成的配置文件过大，不利于后续应用的部署。

发明内容

本申请提供一种配置文件的生成方法及应用部署方法，能够精简生成的目标配置文件。

本申请实施例第一方面提供一种配置文件的生成方法，所述方法包括：在接收到当前触发指令后，确定在接收到前一次触发指令之后，原始chart包中字段值发生改变的至少一个第一目标字段，其中，所述原始chart包是多级chart包，且所述至少一个第一目标字段均处于第一配置文件中；将所述第一配置文件的标识以及每个所述第一目标字段分别对应保存至所述第一配置文件上一级的第二配置文件中；在级别不低于所述第二配置文件的所有第三配置文件中，按照级别从低到高的顺序，依次将所述第三配置文件的标识、对应的目标项对应保存至上一级的所述第三配置文件中，其中，所述第三配置文件对应的所述目标项是在接收到所述前一次触发指令之后，所述第三配置文件中的变化项；根据所述原始chart包中当前的主配置文件，生成目标配置文件，其中，所述主配置文件是所述原始chart包中级别最高的配置文件。

本申请实施例第二方面提供一种应用部署方法，所述方法包括：获取原始chart包；获取所述原始chart包对应的目标配置文件，其中，所述目标配置文件是采用所述的方法生成的；根据所述原始chart包以及所述目标配置文件，进行应用部署。

本申请实施例第三方面提供一种电子设备，所述电子设备包括处理器、存储器以及通信电路，所述处理器分别耦接所述存储器、所述通信电路，所述存储器中存储有程序数据，所述处理器通过执行所述存储器内的所述程序数据以实现上述方法中的步骤。

本申请实施例第四方面提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序能够被处理器执行以实现上述方法中的步骤。

有益效果是：与现有技术中将所有字段均提取至目标配置文件的做法相比，本申请采用的是变量提取的方法，只将发生变化的第一目标字段提取至目标配置文件中，从而能够精简目标配置文件。

附图说明

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

图1是本申请配置文件的生成方法一实施方式的流程示意图；

图2是本申请应用部署方法一实施方式的流程示意图；

图3是对应图2应用部署方法的框架图；

图4是本申请电子设备一实施方式的结构示意图；

图5是本申请电子设备另一实施方式的结构示意图；

图6是本申请电子设备又一实施方式的结构示意图；

图7是本申请计算机可读存储介质一实施方式的结构示意图。

具体实施方式

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

需要说明的是，本申请中的术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在介绍本申请的方案之前，首先简单介绍下有关容器云平台的基础技术：

容器云平台是依靠容器技术，结合云原生技术，采用容器、容器编排、服务网格、无服务等技术构建的一种轻量化pass平台。

Helm渲染器类似linux系统下的包管理器，如yum/apt等，其就可以方便快捷地将之前打包好的yaml文件快速部署进k8s(容器云平台的一种)内，方便管理维护。

其中，Helm渲染器的打包格式叫做chart，所谓chart就是一系列文件的集合，描述了一组相关的k8s集群资源。

目前当想要在容器云平台上部署复杂应用时，单级chart包无法满足需求，需要使用多级chart包，多级chart包与单级chart包不同之处在于，多级chart包具体包括多个层层嵌套的chart包，其中级别最高的是父chart包，且父chart包只有一个，同时父chart包下一级的是子chart包，父chart包下一级的子chart包可以是多个，在这多个子chart包中，只有一个是子主chart包，其他的均是子从chart包，其中，在同一级别的多个子chart包中，只有子主chart包嵌套有下一级的chart包，子主chart包嵌套的下一级chart包是孙chart包，且同一级别的多个孙chart包中，只有一个是孙主chart包，其他的均是孙从chart包，且只有孙主chart包可以嵌套有下一级别的chart包，依次类推。

其中为了便于说明，将除父chart包之外的chart包都定义为子chart包，在同一级别的多个子chart包中，只有一个是子主chart包，其他的均是子从chart包。通过上述介绍可知，子从chart包的上一级是子主chart包，子主chart包的上一级是上一级别的子主chart包，父chart包的级别最高。

在多级chart包中，父chart包、子主chart包、子从chart包、孙主chart包等任何一个chart包都有对应的配置文件，用于存储对应的配置项，其中配置项也就是一个字段，包括字段名和字段值组成，其中字段值不仅仅可以是数值，还可以是任何具有确定含义的字符，例如，“True”或者“False”等。

其中，配置文件之间的嵌套关系与chart包之间的嵌套关系对应，具体而言，子从chart包对应的配置文件的上一级是子主chart包对应的配置文件，子主chart包对应的配置文件的上一级是上一级别的子主chart包对应的配置文件，父chart包对应的配置文件级别最高，其中将父chart包对应的配置文件定义为主配置文件。

下面具体介绍一下chart：

chart是一个具有特定目录树结构和文件的集合，目录名称是chart的名称，如下所示，描述mytest的chart会被存储在mytest目录中：

其中Chart.yaml具体文件结构如下所示：dependencies字段表示当前chart包所依赖的其它chart包，在打包前，通过使用Helm渲染器dependency update(build)的方式，可以将依赖tgz文件下载到charts目录下(oci方式)。也可以在charts目录里，创建子依赖文件夹(在charts目录下，执行Helm create mysubchart)，文件夹名称需要跟Chart目录的dependencies的name保持一致，若同name的dependencies，需要通过alias区别，此时alias的名称就是charts包下的子目录名称。

由于Helm渲染器只能渲染一个可配置文件，因此在现有技术中，当需要编辑多级chart包中子chart包对应的配置文件，需要将子chart包对应的配置文件中的字段全量提取到父chart包的配置文件中，然后利用父chart包的配置文件进行渲染。

这种做法导致父chart包的配置文件过大，编辑和查看繁琐，因此为了避免该缺陷，采用了如下的技术方案：

参阅图1，图1是本申请配置文件的生成方法一实施方式的流程示意图，该方法由安装在电子设备(可以是电脑、手机等任一项具有算法处理能力的设备)上的chart包开发工具执行，该方法包括：

S110：在接收到当前触发指令后，确定在接收到前一次触发指令之后，原始chart包中字段值发生改变的至少一个第一目标字段，其中，原始chart包是多级chart包，且至少一个第一目标字段均处于第一配置文件中。

具体地，原始chart包是多级chart包，在chart包开发工具的界面上，用户可以查看各个chart包的配置文件，并可以对配置文件中的字段进行修改编辑。在用户想要对原始chart包中的某个字段进行修改时，用户可以在chart包开发工具上选中该字段，并输入相应的修改指令，然后chart包开发工具在接收到该修改指令后，根据该修改指令，修改对应字段的字段值。

当前触发指令是当前时刻接收到的触发指令，其中触发指令可以是用户输入修改指令后，点击chart包开发工具界面上某个预设区域(例如空白区域)的指令，或者chart包开发工具界面“下载”按钮的指令，其中，当用户点击“下载”按钮时，表明用户想要下载最终生成的目标配置文件，或者，触发指令还可以是用户将当前配置文件的界面切换为另一个配置文件的界面。

总而言之，触发指令可以是任一个指令，且在接收到触发指令之前，chart包开发工具已经根据接收到的修改指令，对相应字段的字段值进行了修改。

其中，在两次触发指令之间，用户只能对一个配置文件中的字段进行修改，但是可以是只对该配置文件中的一个字段进行修改，也可以是对该配置文件中的多个字段进行修改，其中，将因为用户修改而字段值发生改变的字段定义为第一目标字段，也就是说，在接收到当前触发指令之后，确定的第一目标字段可以是一个，也可以是多个，但均处于同一配置文件中，将该配置文件定义为第一配置文件。

S120：将第一配置文件的标识以及每个第一目标字段分别对应保存至第一配置文件上一级的第二配置文件中。

具体地，在确定第一目标字段后，将每个第一目标字段以及第一配置文件的标识分别对应保存至第二配置文件中，其中，第二配置文件是第一配置文件对应的chart包的上一级的chart包所对应的配置文件，也就是说，第二配置文件是第一配置文件上一级的配置文件。

可以理解的是，保存至第二配置文件中的第一目标字段中的字段值是修改后的字段值。

其中，针对每个第一目标字段而言，具体可以将第一目标字段以及第一配置文件的标识以key-value(一种数据结构)的形式保存至第二配置文件中，其中，第一配置文件的标识对应“key”，第一目标字段对应“value”，也就是说，在保存后的第二配置文件中，可以看出第一目标字段是属于第一配置文件中的字段。

其中，第一配置文件的标识具有唯一性，通过第一配置文件的标识只能查找到第一配置文件。第一配置文件的标识具体可以是第一配置文件的名字(也是第一配置文件所对应chart包的名字)，也可以是别名(也是第一配置文件所对应chart包的别名)，在此不做限制。

可以理解的是，如果在此之前用户已经对第一目标字段进行了编辑修改，那么之前已经在第二配置文件中保存了第一目标字段，因此为了避免第二配置文件过大，步骤S120在保存时，针对每个第一目标字段而言，判断第二配置文件中是否存在与第一目标字段对应的第二目标字段，其中，第二目标字段的字段名与对应的第一目标字段的字段名相同；若存在，则用第一目标字段的字段值覆盖第二配置文件对应的第二目标字段的字段值；若不存在，则在第二配置文件中对应新建第一目标字段以及第一配置文件的标识。

具体地，对于某个第一目标字段而言，如果第二配置文件中已经存在对应的第二目标字段，则说明此前已经对第一目标字段的字段值进行了修改，则直接用第一目标字段的字段值覆盖第二目标字段的字段值，如果不存在对应的第二目标字段，则在第二配置文件中，直接对应新建第一目标字段以及第一配置文件的标识。

需要说明的是，在其他实施方式中，也可以不判断第二配置文件中是否存在第一目标字段对应的第二目标字段，而是直接将第一配置文件的标识以及每个第一目标字段分别对应保存在第二配置文件中。

S130：在级别不低于第二配置文件的所有第三配置文件中，按照级别从低到高的顺序，依次将第三配置文件的标识、对应的目标项对应保存至上一级的第三配置文件中，其中，第三配置文件对应的目标项是在接收到前一次触发指令之后，第三配置文件中的变化项。

具体地，级别不低于第二配置文件的所有第三配置文件包括第二配置文件以及级别高于第二配置文件的所有配置文件。

为了便于理解，在此结合实例对步骤S130进行解释：

假设有4个第三配置文件，分别为级别依次降低的第三配置文件A、第三配置文件B、第三配置文件C以及第三配置文件D，而步骤S130就是先将第三配置文件D的标识、第三配置文件D对应的目标项对应保存在第三配置文件C中，然后将第三配置文件C的标识、第三配置文件C对应的目标项对应保存在第三配置文件B中，最后将第三配置文件B的标识、第三配置文件B对应的目标项对应保存在第三配置文件A中。

其中，将第三配置文件的标识、对应的目标项以key-value的形式保存在上一级的第三配置文件中，其中，第三配置文件的标识对应“key”，对应的目标项对应“value”。

其中，第三配置文件对应的目标项是在接收到前一次触发指令之后，第三配置文件中的变化项，例如，第二配置文件作为第三配置文件，其对应的目标项就是步骤S120在第二配置文件中分别对应保存的每个第一目标字段以及第一配置文件的标识。

其中，对于任意第三配置文件对应的目标项包括其下一级配置文件对应的目标项。

为了便于理解，依旧以上述例子进行说明：

第三配置文件D是第二配置文件，那第三配置文件D对应的目标项就是保存至第三配置文件D中的所有第一目标字段以及第一配置文件的标识，然后将第三配置文件D对应的目标项、标识对应保存在第三配置文件C中，从而第三配置文件C对应的目标项包括第三配置文件D对应的目标项以及第三配置文件D的标识，接着将第三配置文件C对应的目标项、标识对应保存至第三配置文件B中，从而对于第三配置文件B来说，其对应的目标项包括第三配置文件C对应的目标项以及第三配置文件C的标识，最后将第三配置文件B对应的目标项以及第三配置文件B的标识加入第三配置文件A。

可以理解的是，步骤S130不断保存的过程直到主配置文件结束，也就是说，最终会将字段值发生变化的所有第一目标字段均保存至主配置文件中，且在最终得到的主配置文件中，可以看出第一目标字段具体属于哪个配置文件。

从上述内容可以看出，步骤S130不断保存的过程，就是分别在所有第一目标字段上，按照级别从低到高的顺序，依次打上第一配置文件以及与第一配置文件嵌套的上级各个配置文件的标识，最终将得到的内容保存至主配置文件中。

S140：根据原始chart包中当前的主配置文件，生成目标配置文件，其中，主配置文件是原始chart包中级别最高的配置文件。

从上述内容可以看出，字段值发生改变的所有第一目标字段最终均被保存至主配置文件中，且因为在保存过程中，依次打上第一配置文件以及与第一配置文件嵌套的上级各个配置文件的标识，因此从最终得到的当前主配置文件中，根据所有第一目标字段所打上的标识，可以确定第一目标字段所处的第一配置文件。

在一应用场景中，考虑到主配置文件中的字段通常都是高频使用的字段，因此步骤S140直接将当前的主配置文件，确定为目标配置文件。

在另一应用场景中，步骤S140将当前的主配置文件中不同于初始主配置文件的差异项，保存为目标配置文件，其中，初始主配置文件为原始chart包未发生任何改变时的主配置文件。

具体地，初始主配置文件为chart包未发生任何改变时的主配置文件，也就是说，初始主配置文件是用户在未对原始chart包未进行任何编辑之前，原始chart包中的主配置文件。

而当前的主配置文件因为前面进行了合并保存操作，因为所有字段值发生改变的字段都处于当前的主配置文件中，因此从当前的主配置文件不同于初始主配置文件的差异项，可以看出用户对哪些字段进行了修改编辑，因此可以只将当前的主配置文件中不同于初始主配置文件的差异项，保存形成目标配置文件。

总而言之，从目标配置文件中可以确定用户对原始chart包中的哪些字段进行了何种修改。因此后续用户在将目标配置文件进行下载之后，可以根据未进行任何修改时的原始chart包以及目标配置文件，去部署应用，该过程可参见下文介绍。

其中，用户可以根据不同应用场景的需求，对原始chart包进行不同的修改，从而生成不同的目标配置文件，例如，根据应用场景1的需求，生成目标配置文件1，根据应用场景2的需求，生成目标配置文件2，根据应用场景3的需求，生成目标配置文件3，然后根据未进行任何修改时的原始chart包以及目标配置文件1在应用场景1下部署应用，根据未进行任何修改时的原始chart包以及目标配置文件2在应用场景2下部署应用，根据未进行任何修改时的原始chart包以及目标配置文件3在应用场景3下部署应用。

从上述内容可以看出，与现有技术中将所有字段均提取至目标配置文件的做法相比，本申请采用的是变量提取的方法，只将发生变化的第一目标字段提取至目标配置文件中，从而能够精简目标配置文件。

在本实施方式中，在步骤S110之前还包括：

S150：在接收到对第一目标字段进行修改的修改指令后，对修改指令进行校验。

其中，若通过对修改指令的校验，则执行步骤S160，否则执行步骤S170。

S160：根据修改指令对第一目标字段的字段值进行修改。

S170：若校验不通过，则提示修改指令有误。

具体地，在现有技术中，chart包中字段的字段值可以被任意修改，从而存在字段值修改错误，导致后续应用部署失败的现象，而为了避免该现象，在本实施方式中，在接收到对第一目标字段进行修改的修改指令后，根据预设的第一目标字段的修改规则，对修改指令进行校验，若该指令通过校验，则根据该修改指令，对第一目标字段的字段值进行修改，若该修改指令未通过校验，即不符合第一目标字段的修改规则，则进行报错，提示用户重新修改，从而可以拦截错误修改，提高后续应用部署效率。

其中，为了用户能够快速地对错误的修改指令进行修正，本实施方式在提示修改指令有误的同时，还会根据修改指令，生成至少一个候选指令，然后提示至少一个候选指令，以供用户进行选择。

具体地，可以根据第一目标字段的修改规则以及用户输入的修改指令，推测用户想要进行如何修改，然后生成至少一个候选指令，并进行显示，后续用户可以直接从显示的候选指令中选择合适的指令，或者用户根据实际需求直接输入合适的指令。

参阅图2，图2是本申请应用部署方法一实施方式的流程示意图，该方法包括：

S210：获取原始chart包。

具体地，原始chart包是用户未进行任何编辑的chart包。

S220：获取原始chart包对应的目标配置文件。

具体地，原始chart包对应的目标配置文件是采用上述实施方式中的任一项方法得到的，详见可参见上述相关内容，在此不再赘述。

S230：根据原始chart包以及目标配置文件，进行应用部署。

具体地，根据未进行任何修改编辑过的原始chart包以及目标配置文件，进行应用部署。

结合图3，该过程具体包括：Helm渲染器根据原始chart包以及目标配置文件，对原始chart包中的模板文件进行渲染，得到供k8s使用的manifest文件，接着Helm渲染器通过client-go客户端与kube-apiserver建立连接，将manifest文件中的k8s资源部署起来，最终实现应用的部署。

其中，client-go是一个调用kubernetes集群资源对象API的客户端，即通过client-go实现对kubernetes集群中资源对象(包括deployment、service、ingress、replicaSet、pod、namespace、node等)的增删改查等操作。

Kube-apiserver是kubernetes最重要的核心组件之一，提供了集群管理的RESTAPI接口，包括认证授权、数据校验以及集群状态变更等；提供了其他模块之间的数据交互和通信的枢纽。

其中，client-go、kubernetes都属于现有技术，在此不再赘述。

在本实施方式中，Helm渲染器在渲染过程中，目标配置文件中存在的字段以目标配置文件为准，不算在的字段以原始chart包中的配置文件为准，且优先根据目标配置文件渲染原始chart包中的模板文件，也就是说，Helm渲染器先根据目标配置文件渲染原始chart包中的模板文件，然后再根据原始chart包中的配置文件渲染模板文件；最后Helm渲染器根据渲染后的模板文件，完成应用的部署。

其中，基于chart包开发工具生成目标配置文件的用户可以是原始chart包的作者或者熟悉相关业务的开发者，而在前者通过chart包开发工具下载目标配置文件后，可以将未进行任何编辑修改的原始chart包以及目标配置文件交由技术支持或者运维人员，此时技术支持或者运维人员直接就可以通过Helm渲染器进行应用的部署，简单快捷，能够提高应用部署的效率。

参阅图4，图4是本申请电子设备一实施方式的结构示意图，该电子设备200包括处理器210、存储器220以及通信电路230，处理器210分别耦接存储器220、通信电路230，存储器220中存储有程序数据，处理器210通过执行存储器220内的程序数据以实现上述任一项实施方式方法中的步骤，其中详细的步骤可参见上述实施方式，在此不再赘述。

其中，电子设备200可以是电脑、手机等任一项具有算法处理能力的装置，在此不做限制。

参阅图5，图5是本申请电子设备另一实施方式的结构示意图。该电子设备300包括依次连接的确定模块310、保存模块320以及生成模块330。

确定模块310用于在接收到当前触发指令后，确定在接收到前一次触发指令之后，原始chart包中字段值发生改变的至少一个第一目标字段，其中，原始chart包是多级chart包，且至少一个第一目标字段均处于第一配置文件中。

保存模块320用于将第一配置文件的标识以及每个第一目标字段分别对应保存至第一配置文件上一级的第二配置文件中，以及在级别不低于第二配置文件的所有第三配置文件中，按照级别从低到高的顺序，依次将第三配置文件的标识、对应的目标项对应保存至上一级的第三配置文件中，其中，第三配置文件对应的目标项是在接收到前一次触发指令之后，第三配置文件中的变化项。

生成模块330用于根据原始chart包中当前的主配置文件，生成目标配置文件，其中，主配置文件是原始chart包中级别最高的配置文件。

其中，电子设备300在工作时执行上述任一项实施方式中配置文件的生成方法中的步骤，详细的步骤可参见上述相关内容，在此不再赘述。

其中，电子设备300可以是手机、电脑等任一个可以安装chart包开发工具的设备，在此不做限制。

参阅图6，图6是本申请电子设备又一实施方式的结构示意图。该电子设备400包括第一获取模块410、第二获取模块420以及同时与第一获取模块410、第二获取模块420连接的应用部署模块430。

第一获取模块410用于获取原始chart包；第二获取模块420用于获取原始chart包对应的目标配置文件；应用部署模块430用于根据原始chart包以及目标配置文件，进行应用部署。

其中，电子设备400在工作时执行上述任一项实施方式中应用部署方法中的步骤，详细的步骤可参见上述相关内容，在此不再赘述。

其中，电子设备400可以是手机、电脑等任一个具有应用部署能力的设备，在此不做限制。

参阅图7，图7是本申请计算机可读存储介质一实施方式的结构示意图。该计算机可读存储介质500存储有计算机程序510，计算机程序510能够被处理器执行以实现上述任一项方法中的步骤。

其中，计算机可读存储介质500具体可以为U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等可以存储计算机程序510的装置，或者也可以为存储有该计算机程序510的服务器，该服务器可将存储的计算机程序510发送给其他设备运行，或者也可以自运行该存储的计算机程序510。

以上所述仅为本申请的实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本申请的专利保护范围内。