一种针对Helmchart的自动化发布方法技术

本发明专利技术涉及应用自动化发布技术领域，具体提供了一种针对Helmchart的自动化发布方法，具有以下步骤：S1、克隆站点；S2、拷贝推送脚本；S3、获取新旧站点基本信息；S4、拉取基础镜像；S5、比较git_project.yaml文件；S6、处理chart包；S7、根据新旧站点中的基础组件版本确定推送脚本的推送模式。与现有技术相比，本发明专利技术可以让发布应用时消耗更少的成本。通过该自动化方法，可以批量迁移应用的安装介质，在节省人力的同时更能保证迁移的准确性。区分离线及在线模式，更好的适配不同的环境，对于离线环境，可以自动将安装介质拉到文件夹中，凭借硬盘实现迁移。现迁移。现迁移。

【技术实现步骤摘要】
一种针对Helm chart的自动化发布方法


[0001]本专利技术涉及应用自动化发布
，具体提供一种针对Helm chart的自动化发布方法。

技术介绍

[0002]Helm由客户端组件helm和服务端组件Tiller组成，能够将一组K8S资源打包统一管理，是查找、共享和使用为Kubernetes构建的软件的最佳方式。Helm chart是一个描述Kubernetes相关资源的文件集合。
[0003]服务产品的应用通常被制作成chart包，应用的安装依赖于chart及docker镜像作为安装介质，在将应用部署到一个新环境中，通常需要提前将chart包和docker镜像传到环境中后才能执行安装，比较繁琐。

技术实现思路

[0004]本专利技术是针对上述现有技术的不足，提供一种实用性强针对Helm chart的自动化发布方法。
[0005]本专利技术解决其技术问题所采用的技术方案是：
[0006]一种针对Helm chart的自动化发布方法，具有以下步骤：
[0007]S1、克隆站点；
[0008]S2、拷贝推送脚本；
[0009]S3、获取新旧站点基本信息；
[0010]S4、拉取基础镜像；
[0011]S5、比较git_project.yaml文件；
[0012]S6、处理chart包；
[0013]S7、根据新旧站点中的基础组件版本确定推送脚本的推送模式。
[0014]进一步的，在步骤S1中，准备站点的新旧两个分支，且需要两个分支均被执行过构建，克隆到本地后分别存放用于后续的比较。
[0015]进一步的，在步骤S2中，推送脚本是为离线包准备，用于将离线数据的压缩包推送到实际环境中；如果是在线转发模式则会跳过此步骤。
[0016]进一步的，在步骤S3中，获取的基本信息包括架构信息、站点版本、基础组件版本、变量信息、git仓库及镜像仓库；
[0017]所述基础组件版本如果存在差异，则需要及时更新环境中的基础镜像；如果版本一致，则可跳过基础镜像的打包步骤；
[0018]获取所述变量信息主要包括拉取git项目及镜像的源地址、git 项目及镜像的目标推送地址、环境中预置的harbor仓库域名及账户信息。
[0019]进一步的，在步骤S4中，根据新旧版本差异确定是否需要拉取基础镜像，对于离线包，会在拉取后输出为压缩包，在线转发则会给镜像打上目标仓库的tag并执行推送；
[0020]其中，安装包中默认拉取，补丁包中默认不拉取。
[0021]进一步的，在步骤S5中，根据新旧站点中的git_project.yaml 文件进行比较，如果版本不同，或者版本相同但commit_id不同的项目，会记录到拉取列表中，在比较完成后，会启用多线程将列表中所有项目克隆到本地统一文件夹中，克隆完成后，离线模式下会将所用项目打包到压缩包中，站点项目单独打包到另一个压缩包中，在线模式下会启用多线程将项目一次转发到目标仓库。
[0022]进一步的，在步骤S6中，根据新旧站点中的imagelist.yaml文件进行比较，如果tag不同，或者tag相同但image_id不同的项目，会记录到拉取列表中；
[0023]通过docker第三方库确认宿主机上已经存在的镜像，如果 image_id相同，则剔除不再拉取一遍；
[0024]剔除完成后会启用多线程拉取镜像，拉取完成后，在线模式下会启用多线程对镜像重新打tag并推送到目标仓库中，离线模式下，需比较待打包的镜像的image_id与缓存中的是否相同，相同的镜像不再重复打包，不同的再记录到待打包列表中，通过多线程执行save 指令完成打包；
[0025]镜像打包到缓存中，遍历目标文件夹，如果存在相同镜像，则过滤掉不需再次拷贝，如果存在多余镜像，则会清理掉。
[0026]作为优选，image_id分为两种获取方式：
[0027]第一种为记录在站点中的imagelist.yaml文件的，用于判断需要拉取的镜像；
[0028]第二种为拉取后通过docker第三方库即时获取的，用于与缓存中的镜像比较，确定镜像是否需要执行save操作。
[0029]进一步的，在步骤S6中，缓存和目标文件夹中镜像均以tar包格式存储，额外需要image.property文件来记录每个tar包对应的镜像信息。
[0030]进一步的，在步骤S7中，如果版本一致，则仅推送chart包及镜像包；如果版本升级，则额外需要执行基础组件的升级。
[0031]本专利技术的一种针对Helm chart的自动化发布方法和现有技术相比，具有以下突出的有益效果：
[0032]通过本专利技术，可以让发布应用时消耗更少的成本。通过该自动化方法，可以批量迁移应用的安装介质，在节省人力的同时更能保证迁移的准确性。区分离线及在线模式，更好的适配不同的环境，对于离线环境，可以自动将安装介质拉到文件夹中，凭借硬盘实现迁移。
[0033]对于在线环境，即能临时连通办公网络的环境，可以直接将所需机制整理出来并直接推送到目标仓库中，省时省力。支持自定义打包内容，根据实际需要打包，避免了冗余内容，更加高效。
附图说明
[0034]为了更清楚地说明本专利技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本专利技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0035]附图1是一种针对Helm chart的自动化发布方法的流程示意图；
[0036]附图2是一种针对Helm chart的自动化发布方法中打包操作流程示意图；
[0037]附图3是一种针对Helm chart的自动化发布方法中技术架构图。
具体实施方式
[0038]为了使本
的人员更好的理解本专利技术的方案，下面结合具体的实施方式对本专利技术作进一步的详细说明。显然，所描述的实施例仅仅是本专利技术一部分实施例，而不是全部的实施例。基于本专利技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例都属于本专利技术保护的范围。
[0039]下面给出一个最佳实施例：
[0040]如图1
‑
3所示，本实施例中一种针对Helm chart的自动化发布方法，对于升级包来说，具有如下步骤：
[0041]S1、克隆站点：
[0042]准备站点的新旧两个分支，且需要保证两个分支均被执行过构建。克隆到本地后分别存放，用来后续的比较。
[0043]S2、拷贝推送脚本：
[0044]推送脚本是为离线包准备的，用来将离线数据的压缩包推送到实际环境中；如果是在线转发模式则会跳过此步骤。
[0045]S3、获取新旧站点基本信息：
[0046]主要获取站点架构信息、站点版本、基础组件本文档来自技高网...

【技术保护点】

【技术特征摘要】
1.一种针对Helm chart的自动化发布方法，其特征在于，具有以下步骤：S1、克隆站点；S2、拷贝推送脚本；S3、获取新旧站点基本信息；S4、拉取基础镜像；S5、比较git_project.yaml文件；S6、处理chart包；S7、根据新旧站点中的基础组件版本确定推送脚本的推送模式。2.根据权利要求1所述的一种针对Helm chart的自动化发布方法，其特征在于，在步骤S1中，准备站点的新旧两个分支，且需要两个分支均被执行过构建，克隆到本地后分别存放用于后续的比较。3.根据权利要求2所述的一种针对Helm chart的自动化发布方法，其特征在于，在步骤S2中，推送脚本是为离线包准备，用于将离线数据的压缩包推送到实际环境中；如果是在线转发模式则会跳过此步骤。4.根据权利要求3所述的一种针对Helm chart的自动化发布方法，其特征在于，在步骤S3中，获取的基本信息包括架构信息、站点版本、基础组件版本、变量信息、git仓库及镜像仓库；所述基础组件版本如果存在差异，则需要及时更新环境中的基础镜像；如果版本一致，则可跳过基础镜像的打包步骤；获取所述变量信息主要包括拉取git项目及镜像的源地址、git项目及镜像的目标推送地址、环境中预置的harbor仓库域名及账户信息。5.根据权利要求4所述的一种针对Helm chart的自动化发布方法，其特征在于，在步骤S4中，根据新旧版本差异确定是否需要拉取基础镜像，对于离线包，会在拉取后输出为压缩包，在线转发则会给镜像打上目标仓库的tag并执行推送；其中，安装包中默认拉取，补丁包中默认不拉取。6.根据权利要求5所述的一种针对Helm chart的自动化发布方法，其特征在于，在步骤S5中，根据新旧站点中的git_project.yaml文件进行比较，如果版本不同，或者版本相同但commit_id不同的项目，会记录到拉取列表中，在比较完成后，会启用...

【专利技术属性】
技术研发人员：张政，唐晓东，潘峰，
申请(专利权)人：浪潮云信息技术股份公司，
类型：发明
国别省市：