基于容器的发布管理方法及其系统与流程

本申请涉及应用软件的发布，特别涉及基于容器的发布管理技术。

背景技术：

kubernetes(简称k8s)是google开源的容器集群管理系统。在docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。

日常运维进行k8s发布过程中，发布控制机在同一本地环境同时进行多个镜像并发构建管理和镜像清理过程中，往往会出现问题。例如，在日常k8s发布时，进行的操作为：本地拉取代码，构建dockerimage，提交dockerimage，执行k8s命令更新镜像，清理本地镜像缓存。但如果同时进行多个应用的镜像部署，则不同的镜像在不同阶段则会产生相互影响，例如，应用a发布即将完成，开始清理本地缓存，而此时应用b刚好在进行构建dockerimage的操作，则应用a的清理操作会对应用b的构建操作造成影响，清除共同使用的缓存层，导致b的构建失败。此外，在管理多套k8s环境时，如果同时部署的不同应用分属于不同的k8s集群，则会造成集群互斥，发布等待。

技术实现要素：

本申请的目的在于提供一种基于容器的发布管理方法及其系统，解决了多应用部署的环境冲突和步骤冲突问题。

为了解决上述问题，本申请公开了一种基于容器的发布管理方法，包括：

获取n个待发布应用的信息，n为正整数；

根据该信息，对应于每个该待发布应用分别创建一个构建容器和一个发布容器的容器镜像，启动所创建的容器镜像得到构建容器和发布容器；

每个该构建容器为对应的待发布应用构建发布包，提交到容器镜像仓库；

每个该发布容器从该容器镜像仓库拉取对应的待发布应用的发布包，并将该发布包部署到对应的集群；

销毁该构建容器和该发布容器。

在一个优选例中，该获取n个待发布应用的信息之后，还包括：将该待发布应用的信息写入消息队列，按照应用之间的依赖进行排序，生成待发布应用的依赖列表；

该将该发布包部署到对应的集群的步骤中，还进一步包括：

该发布容器根据该依赖列表判断待发布应用是否存在应用之间的依赖；如果不存在依赖，则直接部署该发布包；如果存在依赖，则根据该消息队列中的部署依赖顺序进行等待，直至所依赖的待发布应用完成部署后再部署该发布包。

在一个优选例中，该对应于每个该待发布应用分别创建一个构建容器和一个发布容器的容器镜像的步骤，进一步包括：

根据该待发布应用的信息，获取该待发布应用的应用类型；

从预先生成的容器镜像模板集合中，根据该应用类型匹配得到容器镜像模板；

根据该匹配得到的容器镜像模板创建该构建容器和该发布容器的容器镜像。

在一个优选例中，该容器镜像模板内置对应语言的编译构建环境，分别针对不同的语言，有不同的环境；该容器镜像模板包含对于容器命令的支持；该容器镜像模板配置了对于本地多套kubernates集群的访问权限配置文件。

在一个优选例中，该发布包是一个容器镜像。

在一个优选例中，该待发布应用的信息包括应用名和版本号。

在一个优选例中，该启动所创建的容器镜像得到构建容器和发布容器的步骤之后，还包括：

根据对应的待发布应用的应用类型，该构建容器和发布容器分别读取配置信息，初始化容器内的kubernates环境变量和容器构建环境，执行对应的容器初始化脚本。

本申请还公开了一种基于容器的发布管理系统，包括：

信息获取模块，用于获取n个待发布应用的信息，n为正整数；

容器创建模块，根据该信息，对应于每个该待发布应用分别创建一个构建容器和一个发布容器的容器镜像，启动所创建的容器镜像得到构建容器和发布容器；

构建容器，用于为对应的待发布应用构建发布包，提交到容器镜像仓库；

发布容器，用于从该容器镜像仓库拉取对应的待发布应用的发布包，并将该发布包部署到对应的集群；

销毁模块，用于在该发布包部署完成后销毁该构建容器和该发布容器。

本申请还公开了一种基于容器的发布管理系统，包括：

存储器，用于存储计算机可执行指令；以及，

处理器，用于在执行该计算机可执行指令时实现如前文描述的方法中的步骤。

本申请还公开了一种计算机可读存储介质，该计算机可读存储介质中存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现如前文描述的方法中的步骤。

本申请实施方式中，巧妙地通过利用容器的隔离环境的特性，为同一宿主环境中多个不同的应用并发构建和部署进行了隔离，避免了相互之间的影响，提高了k8s集群应用的部署效率。

本申请的说明书中记载了大量的技术特征，分布在各个技术方案中，如果要罗列出本申请所有可能的技术特征的组合(即技术方案)的话，会使得说明书过于冗长。为了避免这个问题，本申请上述发明内容中公开的各个技术特征、在下文各个实施方式和例子中公开的各技术特征、以及附图中公开的各个技术特征，都可以自由地互相组合，从而构成各种新的技术方案(这些技术方案均因视为在本说明书中已经记载)，除非这种技术特征的组合在技术上是不可行的。例如，在一个例子中公开了特征a+b+c，在另一个例子中公开了特征a+b+d+e，而特征c和d是起到相同作用的等同技术手段，技术上只要择一使用即可，不可能同时采用，特征e技术上可以与特征c相组合，则，a+b+c+d的方案因技术不可行而应当不被视为已经记载，而a+b+c+e的方案应当视为已经被记载。

附图说明

图1是根据本申请第一实施方式的基于容器的发布管理方法流程示意图

图2是根据本申请一个实施例的发布示意图

具体实施方式

在以下的叙述中，为了使读者更好地理解本申请而提出了许多技术细节。但是，本领域的普通技术人员可以理解，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请的实施方式作进一步地详细描述。

本申请的第一实施方式涉及一种基于容器的发布管理方法，其流程如图1所示，该方法包括以下步骤：

在步骤101中，获取n个待发布应用的信息，n为正整数。在一个实施例中，待发布应用的信息包括应用名和版本号等。在一个实施例中，获取n个待发布应用的信息之后，将待发布应用的信息写入消息队列，按照应用之间的依赖进行排序，生成待发布应用的依赖列表。

此后进入步骤102，根据所获取的信息，对应于每个待发布应用分别创建一个构建容器和一个发布容器的容器镜像，启动所创建的容器镜像得到构建容器和发布容器。换句话说，会有2n个容器镜像会被创建和启动，其中包括n个构建容器的容器镜像和n个发布容器的容器镜像。在一个实施例中，根据待发布应用的信息，获取待发布应用的应用类型；从预先生成的容器镜像模板集合(其中包含多个容器镜像模板)中，根据应用类型匹配得到容器镜像模板；根据匹配得到的容器镜像模板创建构建容器和发布容器的容器镜像。其中，容器镜像模板具有以下特点：内置对应语言的编译构建环境，分别针对不同的语言，有不同的环境；包含对于容器命令的支持；配置了对于本地多套kubernates集群的访问权限配置文件。对于一个待发布应用，根据应用类型匹配得到的容器镜像模板可以有两个，一个是构建容器的容器镜像模板，另一个是发布容器的容器镜像模板。

在一个实施例中，在构建容器和发布容器启动之后，根据对应的待发布应用的应用类型，构建容器和发布容器分别读取配置信息，初始化容器内的kubernates环境变量和容器构建环境，执行对应的容器初始化脚本。

此后进入步骤103，每个构建容器为对应的待发布应用构建发布包，提交到容器镜像仓库。

此后进入步骤104，每个发布容器从容器镜像仓库拉取对应的待发布应用的发布包，并将该发布包部署到对应的集群。在一个实施例中，发布包是一个容器镜像。在一个实施例中，发布容器根据依赖列表判断待发布应用是否存在应用之间的依赖。如果不存在依赖，则直接部署发布包。如果存在依赖，则根据消息队列中的部署依赖顺序进行等待，直至所依赖的待发布应用完成部署后再部署发布包。

此后进入步骤105，当一个发布包部署完成后，销毁该发布包所对应的构建容器和发布容器。

在本申请的各个实施方式中，容器可以用docker实现。

在一个实施例中，动态创建docker来进行不同应用的发布示意图如图2所示。

上述技术方案使得统一进行并发多应用部署的互相影响被消除，并使得对于k8s集群环境依赖导致的应用发布串行变为并行，提高发布效率。

为了能够更好地理解本申请的技术方案，下面结合一个具体的例子来进行说明，该例子中罗列的细节主要是为了便于理解，不作为对本申请保护范围的限制。

步骤a，在部署管理系统录入对应的发布应用及对应版本号，例如，对应的json配置如下：

部署系统会将对应的应用信息写入消息队列，按照应用之间的依赖进行排序，生成待发布应用的依赖列表。

步骤b，部署管理系统的发布控制机根据不同的应用构建类型，在系统中预先生成的多个发布执行docker镜像中，匹配出对应的发布执行docker镜像，该镜像用以执行对应的类型的应用构建和应用部署。该镜像具备以下特点：1镜像中内置对应语言的编译构建环境，分别针对不同的语言，有不同的环境，2镜像中包含对于docker命令的支持，3镜像配置了对于本地多套k8s集群的访问权限配置文件。部署任务执行容器主要包含构建容器image，发布执行容器image两种类型，分别单独执行每个应用的构建操作和发布操作。

通过命令创建与待发布应用数量相同的构建容器和发布容器(此时启动的容器数量为2×待发布的应用数量)的docker镜像并启动，写入对应的docker容器的要部署的应用名和版本号配置，目录为/wls/app/appname/version/ver

步骤c，部署管理系统发布控制机在启动部署工作容器后(工作容器包括构建容器和发布容器)，对应的发布应用类型的工作容器读取对应的配置(例如，如果发布应用类型为java就读取java相关的配置，如果发布应用类型为python就读取python相关的配置)，初始化docker容器内的k8s环境变量和docker构建环境，执行对应的容器初始化脚本。

步骤d，与应用数量相同的构建容器启动后，自动连接部署管理系统的消息队列，按照应用的依赖顺序，每个容器依次获取对应的应用名称和版本号，并且开始进行对应应用的构建操作，按照对应的应用类型，执行构建任务，构建发布包的dockerimage，提交到docker镜像仓库。

步骤e,与待发布应用数量相同的发布容器分别从消息队列获取即将部署的应用版本号，根据版本号调用cmdb集群信息接口，获取当前发布容器的集群信息和docker镜像仓库地址，执行对应的k8s待部署的发布包dockerimage拉取操作，拉取完成后，在发布容器内，执行kubectx命令切换到cmdb配置的应用集群，如不存在应用之间的依赖，则执行对应的kubectlsetimage命令，对对应集群的应用进行相关的部署，如当前次发布的应用之间存在依赖，则同时执行的发布容器根据队列中的部署依赖顺序进行相关的发布等待操作，例如以五秒为单位轮询相邻的依赖发布是否发布完成，如发布完成则部署当前发布包，否则继续等待。

步骤f，部署管理系统发起的发布执行容器部署完成后，执行清理发布执行容器的操作，通知发布系统部署完成，发布的最终结果写回到消息队列，销毁本次发布应用的docker容器，包括构建容器和发布容器。

上述技术方案提出了一套新的k8s构建部署管理模式，在多个应用发布时，通过在发布控制机上为多个应用开启不同的容器进行环境的隔离，命令的隔离，来解决发布控制机同一环境下多个应用部署的环境冲突和步骤冲突问题。通过在发布控制机进行应用粒度的容器调度，给每个应用的发布提供了隔离的、单独的、无干扰的docker镜像构建和k8s应用部署的环境，避免了现有技术存在的问题。

本申请的第二实施方式涉及一种基于容器的发布管理系统，该基于容器的发布管理系统包括：

信息获取模块，用于获取n个待发布应用的信息，n为正整数。

容器创建模块，根据信息，对应于每个待发布应用分别创建一个构建容器和一个发布容器的容器镜像，启动所创建的容器镜像得到构建容器和发布容器。

构建容器，用于为对应的待发布应用构建发布包，提交到容器镜像仓库；

发布容器，用于从容器镜像仓库拉取对应的待发布应用的发布包，并将该发布包部署到对应的集群。

销毁模块，用于在发布包部署完成后销毁构建容器和发布容器。

第一实施方式是与本实施方式相对应的方法实施方式，第一实施方式中的技术细节可以应用于本实施方式，本实施方式中的技术细节也可以应用于第一实施方式。

需要说明的是，本领域技术人员应当理解，上述基于容器的发布管理系统的实施方式中所示的各模块的实现功能可参照前述基于容器的发布管理方法的相关描述而理解。上述基于容器的发布管理系统的实施方式中所示的各模块的功能可通过运行于处理器上的程序(可执行指令)而实现，也可通过具体的逻辑电路而实现。本申请实施例上述基于容器的发布管理系统如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，readonlymemory)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

相应地，本申请实施方式还提供一种计算机存储介质，其中存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现本申请的各方法实施方式。

此外，本申请实施方式还提供一种基于容器的发布管理系统，其中包括用于存储计算机可执行指令的存储器，以及，处理器；该处理器用于在执行该存储器中的计算机可执行指令时实现上述各方法实施方式中的步骤。其中，该处理器可以是中央处理单元(centralprocessingunit，简称“cpu”)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，简称“dsp”)、专用集成电路(applicationspecificintegratedcircuit，简称“asic”)等。前述的存储器可以是只读存储器(read-onlymemory，简称“rom”)、随机存取存储器(randomaccessmemory，简称“ram”)、快闪存储器(flash)、硬盘或者固态硬盘等。本发明各实施方式所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

需要说明的是，在本专利的申请文件中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。本专利的申请文件中，如果提到根据某要素执行某行为，则是指至少根据该要素执行该行为的意思，其中包括了两种情况：仅根据该要素执行该行为、和根据该要素和其它要素执行该行为。多个、多次、多种等表达包括2个、2次、2种以及2个以上、2次以上、2种以上。

在本申请提及的所有文献都被认为是整体性地包括在本申请的公开内容中，以便在必要时可以作为修改的依据。此外应理解，在阅读了本申请的上述公开内容之后，本领域技术人员可以对本申请作各种改动或修改，这些等价形式同样落于本申请所要求保护的范围。