动态部署策略优化及持续部署业务保障系统

技术领域

本发明涉及计算机软件技术领域，尤其涉及动态部署策略优化及持续部署业务保障系统。

背景技术

现有部署方式需通过手动方式部署应用于测试环境，并通过测试人员进行测试后才能正式进入生产环境。同时在需对原有应用进行版本更新时，需中止并卸载原有应用再部署新应用。此种升级过程即影响了业务的连续性也增加了新业务上线的效率。在应用升级过程中如发生失败，需手动修复或回滚部署旧版本服务。

发明内容

本发明目的在于提供一种动态部署策略优化及持续部署业务保障系统，用于解决上述现有技术的问题。

本发明一种动态部署策略优化及持续部署业务保障系统，其中，包括：kubernetes计算资源池，通过多种开源工具，提供容器全生命周期管理、持续集成交付和微服务治理服务；容器管理模块，实现所运行服务基本的生命周期管理与流水线；容器管理部署于Kubernetes计算资源池内的所有应用，包含容器的应用管理、租户管理、存储管理、基础设施管理、用户资源使用计量计费、配置管理、集群管理以及对第三方工具的集成中心管理，通过日志管理、监控告警、数据库与中间件对Kubernetes计算资源池内所有组件及应用进行运维管理，以此对容器应用的整个生命周期进行管控，细粒度治理服务应用；镜像仓库，包含容器镜像、第三方仓库的镜像同步、权限管理以及安全扫描，容器管理通过API与镜像仓库连接，在创建应用时，拉取所需镜像并进行部署治理。

根据本发明所述的的动态部署策略优化及持续部署业务保障系统的一实施例，其中，kubernetes计算资源池的多种开源工具包括：镜像仓库Harbor、容器工具Docker、容器性能监控工具Prometheus、应用监控工具Metrics、日志采集工具fluend、日志搜索工具elasticsearch、日志图形展示工具以及Kibana工具。

根据本发明所述的的动态部署策略优化及持续部署业务保障系统的一实施例，其中，分为控制层、数据库层、集群层、镜像仓库层以及后端存储层。

根据本发明所述的的动态部署策略优化及持续部署业务保障系统的一实施例，其中，控制层负责UI操作的汇聚编译，所有的操作都会通过控制层进行处理，控制层将会根据操作的指令分别调用不同模块的API实现，前端使用Rect框架实现，后端通过go语言完成，采用docker容器部署，数据通过数据库层进行存取，可扩展组成集群。

根据本发明所述的的动态部署策略优化及持续部署业务保障系统的一实施例，其中，数据库层存放控制层运行的系统数据和用户各种操作产生的数据，数据类型为字符以及小字段。

根据本发明所述的的动态部署策略优化及持续部署业务保障系统的一实施例，其中，镜像仓库，是平台系统服务镜像和用户运行服务镜像的本地化仓储，基于Harbor实现，提供对服务镜像的版本管理以及服务镜像的安全扫描，结合控制层的对接集成实现不同租户间的仓库组隔离能力，镜像相关数据通过数据库层进行存取，配置多种后端存储类型，进行整体数据实现与服务解耦以及无状态化运行。

根据本发明所述的的动态部署策略优化及持续部署业务保障系统的一实施例，其中，后端存储层是平台存储的集成管理层，集成Ceph分布式存储以及NFS共享型存储，依托Kubernetes的StorageClass、PV以及PVC资源为系统服务及上层应用提供具体的存储卷，后端存储层为每种存储类型提供了相应的Agent插件，集成Ceph时通过Storage-Agent实现操作自动化，在用户有存储卷需求并通过控制层发起后，存储插件将自动的使用Ceph创建rbd块存储设备，并Map到相应节点，并实现自动挂载。

根据本发明所述的的动态部署策略优化及持续部署业务保障系统的一实施例，其中，还包括：DevOps模块，依托容器管理中的集群层实现，用户执行流水线操作后，控制层向DevOps模块发送请求，DevOps模块处理相关请求后，将流水线任务交由集群层完成。

本发明提供一种基于Kubernetes系统的动态部署策略优化及持续部署业务保障的软件应用更新方法，减少部署过程中的人工成本、时间成本、运维成本，并提升开发效率及保障业务应用的可持续运行。

附图说明

图1为动态部署策略优化及持续部署业务保障系统的功能示意图；

图2为容器部署管理的功能示意图；

图3为各层服务通过协议调用完成整体工作流图；

图4为持续集成部署流程图；

图5为DevOps模块依托容器管理中的集群层实现图；

图6为DevOps流水线模块图；

图7为流水线任务中涉及交付的环节示意图。

具体实施方式

为使本发明的目的、内容、和优点更加清楚，下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。

本发明动态部署策略优化及持续部署业务保障系统以kubernetes计算资源池为核心，通过多种开源工具，如镜像仓库Harbor、容器工具Docker、容器性能监控工具Prometheus、应用监控工具Metrics、日志采集工具fluend、日志搜索工具elasticsearch、日志图形展示工具Kibana等工具，以提供容器全生命周期管理、持续集成交付和微服务治理服务。

图1为动态部署策略优化及持续部署业务保障系统的功能示意图，如图1所示，动态部署策略优化及持续部署业务保障方法具体包括：

图2为容器部署管理的功能示意图，如图2所示，容器部署管理，包括：

整体架构设计是分布式、松散耦合的，以保障所有模块、组件的可维护性和可扩展性，通过设计容器管理模块实现所运行服务基本的生命周期管理与流水线，基于Kubernetes、docker技术栈实现，辅以多种生态方法，提供可视化管理工具，实现自动化、智能化运作，实际向下拆分还可分为控制层、数据库层、集群层、镜像仓库层、后端存储层。

容器管理中，应用管理负责应用的生命周期管理；租户管理负责对平台使用的权限管理；存储管理负责对应用存储进行管理；基础设施管理负责对底层主机节点资源进行管理；计量计费针对每个租户资源使用进行资源使用计费模式；配置管理对每个应用的配置文件进行统一管理；集群管理针对底层主机集群进行管理，如主机节点添加、集群添加、资源监控等；集成中心对所有第三方应用功能集成进行管理，如openstack、ceph等。

企业级镜像仓库中，镜像服务提供平台内应用镜像的管理；镜像同步对第三方镜像仓库进行同步；权限管理对镜像使用权限进行管理；安全扫描对平台内镜像进行扫描，发现镜像漏洞。

Kubernetes计算资源池为平台内集群资源池，可管理多个资源池，并对存储资源池进行共享或非共享的分区管理，同时提供应用编排调度、滚动升级、容器网络管理、弹性伸缩、监控日志的管理。

图3将动态部署策略优化及持续部署业务保障系统的功能示意图进行层级化展示，各层服务通过协议调用完成整体工作流图，如图3所示，各层服务通过协议调用完成整体工作流，具体包括：

控制层主要负责UI操作的汇聚编译，所有的操作都会通过控制层进行处理，控制层将会根据操作的指令分别调用不同模块的API实现，前端使用Rect框架实现，后端通过go语言完成，与Kubernetes实现良好的原生协调性，采用docker容器部署，数据通过数据库层进行存取，可扩展组成集群，实现服务高可用。

数据库层主要存放控制层运行的系统数据和用户各种操作产生的数据，数据类型多为字符、小字段，所以选型使用Mysql，其体积小、速度快、安全且稳定，采用集群化部署，互为主从复制，平台提供有备份服务，能手动备份或者自动备份，增加一层灾备保障。

镜像仓库层是平台系统服务镜像和用户运行服务镜像的本地化仓储，基于Harbor实现，提供对服务镜像的版本管理、服务镜像的安全扫描，不同仓库、仓库组之间可快速同步，具备细分的角色权限设定，结合控制层的对接集成实现不同租户间的仓库组隔离能力，镜像相关数据通过数据库层进行存取，可以配置多种后端存储类型如本地存储，对象存储等，整体数据实现与服务解耦、无状态化运行，通过多副本运行方式，提供高可用能力。

后端存储层是平台存储的集成管理层，可以集成多种存储类型，如Ceph分布式存储、NFS共享型存储，集成对接的存储将依托Kubernetes的StorageClass、PV、PVC资源为系统服务及上层应用提供具体的存储卷，后端存储层为每种存储类型提供了相应的Agent插件，如集成Ceph时通过Storage-Agent实现操作自动化，在用户有存储卷需求并通过控制层发起后，存储插件将自动的使用Ceph创建rbd块存储设备，并Map到相应节点，并实现自动挂载。

集群层是平台核心部分，控制层所有操作的实际配置、变更地点，基于Kubernetes实现服务应用的编排、调度管理，以docker为容器运行时选型，整体分为两部分，Master控制节点以及Node计算节点，其中其中控制节点，由三个紧密协作的独立组件组合而成，它们分别是负责API服务的kube-apiserver、负责调度的kube-scheduler，以及负责容器编排的kube-controller-manager。整个集群的持久化数据，则由kube-apiserver处理后保存在Etcd中。

镜像中心是系统服务镜像和用户运行服务镜像的本地化仓储，基于Harbor实现，提供对服务镜像的版本管理、服务镜像的安全扫描，不同仓库、仓库组之间可快速同步，具备细分的角色权限设定，结合控制层的对接集成实现不同租户间的仓库组隔离能力，镜像相关数据通过数据库层进行存取，可以配置多种后端存储类型如本地存储，对象存储等，整体数据实现与服务解耦、无状态化运行，通过多副本运行方式，提供高可用能力。

图4为持续集成部署流程图，展示应用持续部署的交付流程，如图4所示，开发人员将代码上传到GIT代码仓库中，触发静态扫描，并对代码进行编译、镜像打包的动作，由审批人员进行审核通过后，部署于测试集群中，测试人员对该应用进行测试，管理人员将测试人员测试通过的应用镜像发布到运维仓库中并触发新应用部署于准生产环境，由运维人员进行持续的运维。

持续集成部署流程使用自动工作流尽可能覆盖到不同部门的相关人员后，开发人员完成开发后在最后自动部署之前设计审批环节，由开发部门管理员进行审批，审批完成后自动部署到测试部门，测试人员即可进行测试，在通过后由测试人员可发起向运维部门的镜像发布，由测试部门管理员进行审批，审批通过后自动发布到运维部门，运维人员即可部署运行。

部门工作基本都可通过线上完成，每个部门人员可专注自己的工作，降低沟通成本，提供整体效率。设计流水线时，通过事先梳理需要实现的各种工作需求，尽可能将流水线中任务配置清晰、完整，避免因为环节任务欠缺而引发的业务应用的相关问题。

图5为DevOps模块依托容器管理中的集群层实现图，在容器部署管理的功能示意图的基础上添加DevOps服务功能。如图5所示，基于docker+Kubernetes架构实现持续集成和持续发布，DevOps服务中，代码仓库负责对接代码仓库；基础镜像为持续部署使用应用镜像；流水线内可配置多种任务，每个任务将一次进行，模拟人工流水作业；编译构建对代码进行编译及构建；镜像构建对已编译的产物进行打包构建镜像；自动部署启动整个流水线的作业流，进行持续的自动化流水作业。

持续集成强调开发人员提交了新代码之后，立刻进行构建、(单元)测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging环境中更多的测试。

DevOps模块依托容器管理中的集群层实现，用户执行流水线操作后，控制层向DevOps模块发送请求，DevOps模块处理相关请求后，实际将流水线任务交由集群层完成。

图6为DevOps流水线模块图，对持续集成部署流程图内DevOps服务内工作流程进行详细讲解。如图6所示，DevOps manager管理整个持续部署的功能，如创建流水线、添加任务、编译任务分配等；DevOps Operator负责在集群内创建每一个任务模块，每一个Job即为每一个任务Pod，内部已配置定时任务CronJob，Job完成后将运行下一个Job。在这个流水线执行的过程中会对整个流水线内的Job进行持续的日志服务、监控、告警服务等，统一日志、监控、告警方式。

DevOps流水线模块由两层组成，管理层和集群层，管理层主要负责报表展示、流水线编辑、代码仓库管理、指令汇聚编译，基于Python实现，用户操作请求先到DevOps管理层中进行处理，管理层根据用户编排的流水线步骤向集群层传递执行模式，Kubernetes通过Operator管理并完成流水线工作，流水线中每一步都会在集群以Job的方式运行，Job作为计算型任务，有着运行完成就删除的特性，快速回收资源，任务步骤的日志、监控由集群层中日志、监控服务提供，自动模式场景下DevOps管理层通过集成的代码仓库的Hook事件触发，以实现开发人员提交代码后的自动工作流。

图7为流水线任务中涉及交付的环节示意图流水线任务中涉及交付的环节，由缓存卷完成，任务步骤中有产出交付物，需要向下传递时，可以向后端存储层申请存储卷，并挂载到相依应的任务步骤中，实际为将缓存卷挂载到Job所运行容器的文件夹下，步骤完成时，缓存卷自动挂载到下一个步骤任务的Job所所运行容器的文件夹下，提供文件传递。

流水线中，如果选择构建镜像(基础镜像中选择构建镜像的某一项)，流水下任务将自动获取代码(git pull)，并在基础镜像启动的容器环境中，查找代码项目下指定目录的Dockerfile，并按照docker build的标准方式进行构建。因此，子任务所指向的代码项目中，需要包含可将该项目制作成镜像的Dockerfile，或在流水线任务构建时指定并设置云端Dockerfile。

代码编译的基础镜像中包含了程序语言编译所需的运行环境和依赖代码库，代码编译的过程将在该基础镜像中运行。因此，用户需要选择对应且正确的基础镜像来完成编译。当提供的基础镜像无法满足需求时，用户或管理员可自行制作自定义的基础镜像。

构建提供多种代码构建工具，支持包括Jenkins、Ant、Maven、Gradle等多种常用构建工具，并集成到开发流水线中，统一创建构建任务、统一管理、统一执行。同时还支持数据库脚本的部署，连接数据库信息等密文展示，且能校验数据库脚本执行结果，提供MySQL数据库模板，及数据库容器实例弹性扩展策略(即弹性扩展的脚本)。

本发明方法，使用容器作为部署环境，针对传统部署方式进行优化，使部署人员可以定制动态部署策略，部署方式将以策略持续进行，并且在升级过程中不中断原有服务，平滑升级至新版本，同时在升级失败时自动回滚至旧版本服务，保障业务的连续性。

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