CN106293820A - 开发测试运维一体化系统、部署、全量以及增量更新方法 - Google Patents

Abstract

本发明公开了开发测试运维一体化系统、部署、全量以及增量更新方法，包括：自动部署模块，在开发者端根据镜像仓库中的镜像配置相应备份控制器信息和负载均衡器信息，自动生成应用部署脚本，自动/手动扩散到测试部署端；测试部署端通过执行应用部署脚本文件将应用自动部署到测试运维环境；自动更新模块，在开发者端根据镜像仓库中的镜像将应用程序更新，采用全量更新或增量更新方式，生成更新包文件，自动/手动扩散到测试部署端；测试部署端通过执行更新包文件将更新后的应用自动部署到测试运维环境。本发明减少开发、测试和运维之间的合作障碍，提高协作效率，简化应用的部署流程，让开发人员关注业务流程本身，降低对运维人员技术水平的要求。

Description

开发测试运维一体化系统、部署、全量以及增量更新方法

技术领域

本发明涉及计算机云计算领域，构建一种开发测试运维一体化系统、部署、全量以及增量更新方法。

背景技术

微服务架构是将细粒度服务开发成单一应用的架构模式。微服务可以使用不同的开发语言以及不同数据存储技术实现应用开发，并保持最低限制的集中式管理。

随着云计算时代的到来，平台即服务(Platform as a Service，简称PaaS)得到了蓬勃的发展，PaaS市场也将成为云计算创新企业激烈竞争的下一个领域。如何构建基于云计算的服务模式，为租户提供更有效、便捷、安全及支持个性化和多元化的服务，是一个非常值得探讨的问题。Docker作为PaaS其中重要的组件，使得部署PaaS更为简单，并使其有更大的发挥空间。

Docker是一个开源自动化部署引擎，它可以将任何应用封装成一个简单、便携、不依赖于其他组件的容器，从而轻松地将其部署在各种虚拟环境中，以便进行开发和运维。具体说来，Docker在开发和运维过程中，具有如下几个方面的优势。

更快速的交付和部署。使用Docker，开发人员可以使用镜像来快速构建一套标准的开发环境；开发完成之后，测试和运维人员可以直接使用相同环境来部署代码。其中，镜像是一个包含程序运行必要依赖环境和代码的只读文件。

更高效的资源利用。Docker容器的运行不需要额外的虚拟化管理程序支持，它是内核级的虚拟化，可以实现更高的性能，并且对资源的额外需求很低。

更便捷的迁移和扩展。Docker容器可以在多种平台上运行，利用这种兼容性让用户可以在不同平台之间轻松地迁移应用。

更简单的更新管理。只需要细微的配置修改，就可以替代以往大量的更新工作。并且所有修改都以增量的方式进行分发和更新，从而实现自动化和高效的容器管理。

由于其基于LXC(Linux Container)的轻量级虚拟化技术，Docker最明显的特点就是启动快，资源占用小。因此对于构建隔离的标准化的运行环境，轻量级的PaaS平台，以及自动化测试和持续集成环境，Docker可以充分发挥其优势。

但是，在物理机上创建Docker容器时，需要开发者手动查询多个待调度的物理机的配置信息，如物理机的CPU、内存、硬盘以及在该物理机上创建Docker容器的数量，进而人工判断该物理机上是否能够创建新的Docker容器，再逐步手动建立。而且对于已创建好的Docker容器，仍需手动去查询和管理。可见，目前Docker容器的管理方式不灵活，不智能，效率低，亟待需要自动化管理工具来管理Docker容器。

随着Docker的发展，Docker的生态圈也越来越成熟，Kubernetes等开源的第三方Docker管理工具应运而生。

kubernetes是Google开源的容器集群管理系统，它构建Docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，利用kubernetes能方便地管理跨机器运行容器化的应用，其主要功能如下：

1)使用Docker对应用程序包装、实例化、运行。

2)以集群的方式运行、管理跨机器的容器。

3)解决Docker跨主机容器之间的通讯问题。

4)kubernetes的自我修复机制，保证系统运行的健壮性。

发明内容

本发明的目的就是为了解决上述问题，提供一种开发测试运维一体化系统、部署、全量以及增量更新方法，它具有支持快速构建、部署各类应用系统，屏蔽云计算技术细节，支持动态构建、管理应用之间以及应用模块之间的协同关系链，屏蔽应用协同化技术细节的优点。

为了实现上述目的，本发明采用如下技术方案：

开发测试运维一体化系统，包括：

镜像管理模块，被配置为查询和删除已构建镜像，构建自定义镜像并上传到镜像仓库；

镜像仓库模块，被配置为存储镜像的详细信息；

自动部署模块，用于在开发者端根据镜像仓库中的镜像配置相应备份控制器信息和负载均衡器信息，自动生成应用部署脚本，自动/手动扩散到测试部署端；测试部署端通过执行应用部署脚本文件将应用自动部署到测试运维环境；

自动更新模块，被配置为在开发者端根据镜像仓库中的镜像将应用程序更新，根据不同的业务需求，采用全量更新或增量更新方式，生成更新包文件，自动/手动扩散到测试部署端；测试部署端通过执行更新包文件将更新后的应用自动部署到测试运维环境。

开发测试运维一体化系统，还包括：

集群管理模块，用于查询和管理自动部署模块和自动更新模块创建应用集群的实时数据。

集群监控模块，实时监控应用集群中各个节点的指标；

平台信息管理模块，用于查询应用集群基本信息。

日志监控模块，根据应用集群基本信息，实现对Docker容器和应用集群的日志收集，包括历史日志和实时日志。

备份控制器用于控制Pod的备份，解决Pod的扩容缩容问题；负载均衡器用于控制Pod的逻辑关系以及Pod的访问规则。

所述构建自定义镜像包括：自定义镜像名称、镜像级别、依赖镜像、开放端口或设置环境变量。

所述镜像的详细信息包括：镜像名称、镜像拥有者、镜像级别、依赖镜像名称或镜像描述信息。

所述应用集群中各个节点的指标包括：CPU使用率、内存使用率、网络吞吐量以及磁盘空间利用率。

所述应用集群的实时数据包括集群名称、集群标识、关联实例名称、关联副本数量，以及对集群Service的配置修改和更新。

集群Service是Kubernetes最外围的单元，通过虚拟一个访问IP及服务端口，可以访问已经定义的Pod资源；Pod是Kubernetes系统中，可以被创建、销毁、调度、管理的最小的部署单元。

所述应用集群基本信息包括物理主机基本信息、备份控制器(ReplicationController)基本信息、负载均衡基本信息、应用实例基本信息，负载均衡器路由的更新信息、应用实例路由的更新信息。

所述物理主机基本信息包括：物理主机名称、物理主机标识、物理主机状态、CPU使用率或可用内存量。

所述备份控制器基本信息包括：备份控制器名称、备份控制器标识、运行副本数量、关联实例或副本状态。

所述负载均衡器基本信息包括：负载均衡器名字、所属端口、关联实例、所属IP地址或所处主机端口。

所述应用实例基本信息包括：应用实例名称、应用实例标识、开放的端口、虚拟IP地址、所属主机IP、开放的主机端口、运行状态或日志监控。

所述日志监控模块使用Flume工具，直接读取和收集容器在宿主机上的日志信息。

开发测试运维一体化系统的自动部署方法，包括如下步骤：

步骤101：镜像创建：选择依赖镜像，配置镜像信息，并上传所需应用程序包；

步骤102：进行开发内部测试，根据镜像创建Pod检测应用程序能否正确运行；当判断结果为“否”时，返回步骤101，重新配置镜像信息；当判断结果为“是”时，进入步骤103；

步骤103：测试应用程序能否正确运行；当判断结果为“否”时，返回步骤101，重新配置镜像信息；当判断结果为“是”时，进入步骤104；

步骤104：对备份控制器信息和负载均衡器信息分别进行配置，完成应用部署脚本的创建；

步骤105：通过执行应用部署脚本文件将应用自动部署到生产环境。

开发测试运维一体化系统的全量更新方法，包括如下步骤：

步骤201：假设需要被更新的基础镜像为Base:v1，将镜像Base:v1更新为镜像Base:v2，并将Base:v2上传到镜像仓库模块中；

步骤202：在镜像仓库模块中读取镜像之间的继承关系，发现镜像Child继承自镜像Base:v1，而镜像Base:v1已经被镜像Base:v2更新，那么镜像Child的父镜像需要更改为镜像Base:v2；

步骤203：通过修改layer文件将镜像Child的parent ID更新为镜像Base:v2的ID；判断是否需要更新；当需要更新时，进入步骤204；当不需要更新时，结束；

步骤204：读取有关镜像Child的备份控制器的配置信息，保持配置信息不变，创建一个新的Child的备份控制器；

根据创建的新的Child的备份控制器，判断每一个Pod是否启动正常；启动正常时，将新建的Child的备份控制器添加到Service中，并删除旧的配置信息；删除旧的备份控制器，结束；启动不正常时，删除不可用的Child的备份控制器；返回步骤204。

开发测试运维一体化系统的增量更新方法，包括如下步骤：

步骤301：假设需要局部更新的镜像为A，将镜像A上传到镜像仓库中；

步骤302：将需要被更新的文件制作成镜像B；

步骤303：将镜像A中的文件的layerID修改为镜像B中的文件的layerID；判断是否需要更新；当判断结果为是时，进入步骤304；当判断结果为否时，结束；

步骤304：读取有关Child的备份控制器的配置信息，保持配置信息不变，创建一个新的Child的备份控制器；根据创建的新的备份控制器，判断每一个Pod是否启动正常；当判断结果为是时，将新建的备份控制器添加到Service中，并删除旧的配置信息；删除旧的备份控制器；结束；当判断结果为否时，删除不可用的备份控制器；返回步骤304。

本发明的有益效果是：

通过设计一种云服务领域的开发测试运维自动部署技术，构建一种基于微服务架构的开发测试运维一体化装置，能够在云服务领域实现应用从开发环境自动部署到生产环境，实现开发测试运维一体化。

本发明减少开发、测试和运维之间的合作障碍，有效提高三者之间的协作效率，简化应用的部署流程，让开发人员更多地关注业务流程本身，降低对运维人员技术水平的要求。这种工作模式可以提高应用的开发速度，实现软件或应用程序的快速部署，为软件企业带来更多效益。

本发明根据不同的业务需求，提出了两种不同的更新机制，简化了更新流程，降低了更新损失。通过开发测运维试一体化平台，简化了环境配置，快速构建应用，简化开发流程；通过快速构建集群，降低了运维流程。

附图说明

图1为本发明中系统应用结构示意图；

图2为本发明中自动部署实施例流程图；

图3为本发明中全量更新实施例流程图；

图4为本发明中增量更新实施例流程图。

具体实施方式

下面结合附图与实施例对本发明作进一步说明。

本发明实施例公开了一种基于微服务架构的开发测试运维一体化系统，参见图1所示，所述系统包括：

镜像管理模块，用于查询和删除已构建镜像以及构建自定义镜像。

镜像仓库模块：被配置为查询和更新镜像的详细信息。

自动部署模块，用于开发者端配置相应备份控制器和负载均衡器信息生成应用部署脚本，自动/手动扩散到测试部署端。测试部署端通过执行应用部署脚本文件将应用自动部署到测试运维环境。

自动更新模块：被配置为在开发者端将应用程序更新，生成更新包文件，自动/手动扩散到测试部署端；测试部署端通过执行更新包文件将更新后的应用自动部署到测试运维环境。

集群监控模块，实时监控集群中各个节点的各项指标，包括：CPU使用率、内存使用率、网络吞吐量以及磁盘空间利用率等。

集群管理模块，用于查询集群实时数据，包括集群名称、集群标识、关联实例名称、关联副本数量，以及对集群Service的配置修改和更新。

平台信息管理模块：用于查询开发测试运维一体化系统基本信息。

日志监控模块：实现对Docker容器和应用集群的日志收集，包括历史日志和实时日志。

下面以一个实施例对应用自动部署过程进行具体的阐述。如图2所示，

步骤101：镜像创建：选择依赖镜像，配置镜像信息，并上传所需应用程序包；

步骤102：进行开发内部测试，根据镜像创建Pod检测应用程序能否正确运行；当判断结果为“否”时，返回步骤101，重新配置镜像信息；当判断结果为“是”时，进入步骤103；

步骤103：测试应用程序能否正确运行；当判断结果为“否”时，返回步骤101，重新配置镜像信息；当判断结果为“是”时，进入步骤104；

步骤104：对备份控制器信息和负载均衡器信息分别进行配置，完成应用部署脚本的创建；

步骤105：通过执行应用部署脚本文件将应用自动部署到生产环境。

步骤106：测试人员通过执行应用部署脚本文件将应用自动部署到生产环境。

如图3所示，本发明实施例提供一种镜像全量更新的方法，该方法包括以下几个步骤：

步骤201：假设需要被更新的基础镜像为Base:v1，将镜像Base:v1更新为镜像Base:v2，并将Base:v2上传到镜像仓库模块中；

步骤202：在镜像仓库模块中读取镜像之间的继承关系，发现镜像Child继承自镜像Base:v1，而镜像Base:v1已经被镜像Base:v2更新，那么镜像Child的父镜像需要更改为镜像Base:v2；

步骤203：通过修改layer文件将镜像Child的parent ID更新为镜像Base:v2的ID；判断是否需要更新；当需要更新时，进入步骤204；当不需要更新时，结束；

步骤204：读取有关镜像Child的备份控制器的配置信息，保持配置信息不变，创建一个新的Child的备份控制器；

根据创建的新的Child的备份控制器，判断每一个Pod是否启动正常；启动正常时，将新建的Child的备份控制器添加到Service中，并删除旧的配置信息；删除旧的备份控制器，结束；启动不正常时，删除不可用的Child的备份控制器；返回步骤204。

如图4所示，本发明实施例提供一种镜像增量更新的方法，该方法包括以下几个步骤：

步骤301：假设需要局部更新的镜像为A，将镜像A上传到镜像仓库中；

步骤302：将需要被更新的文件制作成镜像B；

步骤303：将镜像A中的文件的layerID修改为镜像B中的文件的layerID；判断是否需要更新；当判断结果为是时，进入步骤304；当判断结果为否时，结束；

步骤304：读取有关Child的备份控制器的配置信息，保持配置信息不变，创建一个新的Child的备份控制器；根据创建的新的备份控制器，判断每一个Pod是否启动正常；当判断结果为是时，将新建的备份控制器添加到Service中，并删除旧的配置信息；删除旧的备份控制器；结束；当判断结果为否时，删除不可用的备份控制器；返回步骤304。

上述虽然结合附图对本发明的具体实施方式进行了描述，但并非对本发明保护范围的限制，所属领域技术人员应该明白，在本发明的技术方案的基础上，本领域技术人员不需要付出创造性劳动即可做出的各种修改或变形仍在本发明的保护范围以内。

Claims (10)

1.开发测试运维一体化系统，其特征是，包括：

镜像管理模块，被配置为查询和删除已构建镜像，构建自定义镜像并上传到镜像仓库；

镜像仓库模块，被配置为存储镜像的详细信息；

自动部署模块，用于在开发者端根据镜像仓库中的镜像配置相应备份控制器信息和负载均衡器信息，自动生成应用部署脚本，自动/手动扩散到测试部署端；测试部署端通过执行应用部署脚本文件将应用自动部署到测试运维环境；

自动更新模块，被配置为在开发者端根据镜像仓库中的镜像将应用程序更新，根据不同的业务需求，采用全量更新或增量更新方式，生成更新包文件，自动/手动扩散到测试部署端；测试部署端通过执行更新包文件将更新后的应用自动部署到测试运维环境。

2.如权利要求1所述的开发测试运维一体化系统，其特征是，还包括：

集群管理模块，用于查询和管理自动部署模块和自动更新模块创建应用集群的实时数据；

集群监控模块，实时监控应用集群中各个节点的指标；

平台信息管理模块，用于查询应用集群基本信息；

日志监控模块，根据应用集群基本信息，实现对Docker容器和应用集群的日志收集，包括历史日志和实时日志。

3.如权利要求1所述的开发测试运维一体化系统，其特征是，所述构建自定义镜像包括：自定义镜像名称、镜像级别、依赖镜像、开放端口或设置环境变量。

4.如权利要求1所述的开发测试运维一体化系统，其特征是，所述镜像的详细信息包括：镜像名称、镜像拥有者、镜像级别、依赖镜像名称或镜像描述信息。

5.如权利要求2所述的开发测试运维一体化系统，其特征是，所述应用集群中各个节点的指标包括：CPU使用率、内存使用率、网络吞吐量以及磁盘空间利用率。

6.如权利要求2所述的开发测试运维一体化系统，其特征是，所述应用集群的实时数据包括集群名称、集群标识、关联实例名称、关联副本数量，以及对集群Service的配置修改和更新。

7.如权利要求2所述的开发测试运维一体化系统，其特征是，所述应用集群基本信息包括物理主机基本信息、备份控制器基本信息、负载均衡基本信息、应用实例基本信息，负载均衡器路由的更新信息、应用实例路由的更新信息。

8.采用如权利要求1所述的系统的自动部署方法，其特征是，包括如下步骤：

步骤101：镜像创建：选择依赖镜像，配置镜像信息，并上传所需应用程序包；

步骤102：进行开发内部测试，根据镜像创建Pod检测应用程序能否正确运行；当判断结果为“否”时，返回步骤101，重新配置镜像信息；当判断结果为“是”时，进入步骤103；

步骤103：测试应用程序能否正确运行；当判断结果为“否”时，返回步骤101，重新配置镜像信息；当判断结果为“是”时，进入步骤104；

步骤104：对备份控制器信息和负载均衡器信息分别进行配置，完成应用部署脚本的创建；

步骤105：通过执行应用部署脚本文件将应用自动部署到生产环境。

9.采用如权利要求1所述的系统的全量更新方法，其特征是，包括如下步骤：

步骤201：假设需要被更新的基础镜像为Base:v1，将镜像Base:v1更新为镜像Base:v2，并将Base:v2上传到镜像仓库模块中；

步骤202：在镜像仓库模块中读取镜像之间的继承关系，发现镜像Child继承自镜像Base:v1，而镜像Base:v1已经被镜像Base:v2更新，那么镜像Child的父镜像需要更改为镜像Base:v2；

步骤203：通过修改layer文件将镜像Child的parent ID更新为镜像Base:v2的ID；判断是否需要更新；当需要更新时，进入步骤204；当不需要更新时，结束；

步骤204：读取有关镜像Child的备份控制器的配置信息，保持配置信息不变，创建一个新的Child的备份控制器；

根据创建的新的Child的备份控制器，判断每一个Pod是否启动正常；启动正常时，将新建的Child的备份控制器添加到Service中，并删除旧的配置信息；删除旧的备份控制器，结束；启动不正常时，删除不可用的Child的备份控制器；返回步骤204。

10.采用如权利要求1所述的系统的增量更新方法，其特征是，包括如下步骤：

步骤301：假设需要局部更新的镜像为A，将镜像A上传到镜像仓库中；

步骤302：将需要被更新的文件制作成镜像B；

步骤303：将镜像A中的文件的layerID修改为镜像B中的文件的layerID；判断是否需要更新；当判断结果为是时，进入步骤304；当判断结果为否时，结束；

步骤304：读取有关Child的备份控制器的配置信息，保持配置信息不变，创建一个新的Child的备份控制器；根据创建的新的备份控制器，判断每一个Pod是否启动正常；当判断结果为是时，将新建的备份控制器添加到Service中，并删除旧的配置信息；删除旧的备份控制器；结束；当判断结果为否时，删除不可用的备份控制器；返回步骤304。