一种基于容器云的应用集成和发布方法及系统与流程

本发明涉及计算机数据处理技术领域，特别是涉及一种基于容器云的应用集成和发布方法及系统。

背景技术：

容器为用户打开了一扇通往新世界的大门，真正进入容器的世界后，却发现新的生态系统如此庞大。在生产使用时，无论是个人还是企业，都会提出更复杂的需求。这时，我们需要众多跨主机的容器协同工作，需要支持各种类型的工作负载，企业级应用开发更是需要基于容器技术，实现支持多人协作的应用集成、应用发布平台。即使docker只需一条命令便可启动一个容器，一旦试图将其推广到开发测试环境和生产环境中，麻烦便层出不穷，容器相关的网络、存储、集群、高可用等就是不得不面对的问题。从容器到容器云的进化便应运而生。

容器云的本质是一个轻量级的容器虚拟化平台，以及一套标准的开发、构建、部署、运行的流程，并且可以集成各类工具，比如持续集成、数据库与缓存、大数据等，以及一些paas类的服务。容器云在计算资源调度上具备iaas的灵活性，以及paas的便利，应用发布/更新、弹性伸缩、日志监控、滚动升级、持续集成/部署等系统级的paas服务已成为容器云的标配，并逐渐会往上层发展，比如部署数据库与缓存、大数据、安全监控等服务，以及集成各类saas服务。

目前在开发测试环境和生产环境中基于容器云应用的传统发布模式如图1。当进行容器云的应用发布时，应用发布人员首先需编写该应用的发布脚本，其中脚本内容的格式为该容器云应用发布的格式规范，脚本的内容主要包括：应用名称、应用镜像名称、应用资源配置、应用环境变量和目录映射配置、应用健康检查配置以及应用启动命令和启动的应用容器个数等。当配置完应用发布脚本后，需对该脚本进行格式规范检查，以确认编写的脚本是否正确，检查完应用发布脚本后，在终端执行应用发布命令，此时容器云的计算节点将根据应用发布脚本中的镜像名称从镜像仓库中拉取对应镜像至本地计算节点上，同时根据应用发布脚本中的其他配置信息在本地计算节点上启动对应的应用容器，如图1所示，在容器云的计算资源池中启动了4个相同的应用容器。

现有的基于容器云的应用集成和发布方法存在以下问题：(1)应用包发布配置文件是由应用发布人员编写并保存在容器云环境的本地，不易于管理，尤其是当应用进行不断的更新升级后，同一个应用将会有很多个版本及其对应的应用包发布配置文件，当版本过多时，应用版本管理将会异常复杂；(2)对于应用包发布配置文件的编写需由专业人员进行，而在企业应用或公有的容器云环境中，实际使用应用的人员对容器云本身并不熟悉，无法进行应用发布配置文件的编写，此时即使拥有充足的资源，也无法顺畅的通过容器充分的使用起来。

技术实现要素：

为了弥补上述现有技术的不足，本发明提出一种基于容器云的应用集成和发布的方法及系统。

本发明的技术问题通过以下的技术方案予以解决：

一种基于容器云的应用集成和发布的方法，包括如下步骤：

s1、根据应用的配置信息集成所述应用的应用包发布配置文件；

s2、配置所述应用的应用包版本信息；

s3、存储所述应用的应用包发布配置文件和应用包版本信息；

s4、根据用户发送的应用发布api请求，获取所述应用的配置信息和版本信息；

s5、根据所述应用的配置信息和版本信息，获取所述应用的镜像信息；

s6、根据所述镜像信息，查找所述应用的镜像文件；若所述应用的镜像文件存在，则反馈镜像文件存在信息；若所述应用的镜像文件不存在，则触发应用管理人员制作所述应用的镜像文件，制作完成后，反馈镜像文件存在信息；

s7、根据所述镜像文件存在信息，将所述应用发布至容器云平台。

在一些优选地实施例中，在步骤s1中，所述应用包发布配置文件的集成方法包括如下步骤：

t1、创建chart目录和所述chart目录下的文件及目录；其中，所述文件和目录包括chart.yaml文件、license文件、readme.md文件、requirements.yaml文件、values.yaml文件、charts目录、templates目录和templates/notes.txt文件；

t2、配置所述chart.yaml文件；其中，所述chart.yaml文件的配置信息包括应用名称、应用描述、应用版本信息和应用维护人员信息；

t3、配置所述requirements.yaml文件；其中，所述requirements.yaml文件的配置信息包括依赖应用的应用名称、依赖应用的应用版本、依赖应用的发布配置文件信息的完整url；

t4、配置所述templates目录中的模板文件；其中，所述模板文件遵循用于编写go模板的标准约定，所述模板文件中添加了来自spring库的60个附加模板函数以及专用函数specializedfunctions。

在一些优选地实施例中，所述配置信息包括应用名称、应用镜像名称、应用资源配置、应用环境变量和目录映射配置、应用健康检查配置以及应用启动命令和启动的应用容器个数等。

在一些优选地实施例中，在步骤s1中，所述应用包版本信息的构建，遵循semver2标准。

本发明还提出一种基于容器云的应用集成和发布的系统，包括：

应用包管理中心，用于根据应用的配置信息集成所述应用的应用包发布配置文件，配置所述应用的应用包版本信息，并存储所述应用的应用包发布配置文件和应用包版本信息；

应用发布管理器，用于接收用户发送的应用发布api请求，根据所述应用发布api请求，从所述应用包管理中心获取所述应用的配置信息和应用包版本信息；

镜像仓库，用于根据所述应用的配置信息和版本信息，从所述应用包管理中心获取所述应用的镜像信息；并根据所述镜像信息，查找所述应用的镜像文件；若所述应用的镜像文件存在，则反馈镜像文件存在信息至所述应用发布管理器；若所述应用的镜像文件不存在，则触发应用管理人员制作所述应用的镜像文件，制作完成后，反馈镜像文件存在信息至所述应用发布管理器；

容器云平台，用于接收并运行所述应用发布管理器根据所述镜像文件存在信息发布的应用。

在一些优选地实施例中，所述应用包管理中心包括：

应用包配置管理单元，用于根据应用的配置信息集成所述应用的应用包发布配置文件；

应用包版本管理单元，用于配置所述应用的应用包版本信息；

应用包存储管理单元，用于存储所述应用的应用包发布配置文件和应用包版本信息。

在一些优选地实施例中，所述配置信息包括应用名称、应用镜像名称、应用资源配置、应用环境变量和目录映射配置、应用健康检查配置以及应用启动命令和启动的应用容器个数。

在一些优选地实施例中，所述应用包版本信息的构建，遵循semver2标准。

本发明与现有技术对比的有益效果包括：

在应用发布前，可将应用发布配置信息集成到容器云的应用包管理中心，当进行应用发布时，用户可在应用包管理中心查找需要的应用及其对应的版本并进行应用发布，可极大的节省应用发布的时间，降低应用发布的出错率；当应用的应用包经过几次更新迭代后，应用包管理中心可对应用的版本进行统一的管理；另外，对于通用的中间件应用，如mysql、redis、tomcat等，可直接将应用发布配置信息和版本信息集成到应用包管理中心，此后，在任何地方可拿到即用，无需再对应用发布做任何的信息配置，可极大的提高应用发布配置信息的可重用性，节省容器云平台的发布部署时间，同时降低应用发布的出错率。

附图说明

图1是基于容器云应用的传统发布模式的系统架构图；

图2是本发明某一实施例中基于容器云的应用集成和发布系统的架构图；

图3是本发明某一实施例中基于容器云的应用集成和发布系统的工作流程图。

具体实施方式

下面对照附图并结合优选的实施方式对本发明作进一步说明。

参考图3，本实施例中的基于容器云的应用集成和发布的方法，包括如下步骤：

s1、根据应用的配置信息集成所述应用的应用包发布配置文件：

在进行应用发布前，首先应根据所述应用的配置信息进行所述应用的应用包发布配置文件的集成，容器云的应用包发布配置文件由一组称作chart的目录文件集合组成，应用包管理中心的应用包配置管理器根据如下方法来构建当前的应用包发布配置文件：

(1)创建chart目录和chart目录下的文件及目录，包括chart.yaml文件、license文件、readme.md文件、requirements.yaml文件、values.yaml文件、charts目录、templates目录和templates/notes.txt文件；其中，所述文件和目录的含义如下：

chart.yaml文件：包含应用信息的yaml文件；

license文件：包含chart许可证的纯文本文件；

readme.md文件：可读的自述文件；

requirements.yaml文件：该应用对于其他应用的依赖关系列表；

values.yaml文件：应用发布的默认配置文件；

charts目录：一个包含该应用依赖的所有其他应用发布配置目录信息；

templates目录：一个模板目录，当和values结合时，将生成容器云的发布配置；

templates/notes.txt文件：简短的纯文本使用说明文件；

(2)配置chart目录下的chart.yaml文件，该文件主要包含应用名称、应用描述信息、应用版本信息、应用维护人员信息等信息；

(3)配置chart目录下的requirements.yaml文件，该文件是列出当前应用依赖的其他应用的文件，主要需要配置三个字段：依赖应用的应用名称、依赖应用的应用版本、依赖应用的发布配置文件信息的完整url；

(4)创建并配置chart目录下的templates目录中的模板文件，该模板文件需遵循用于编写go模板的标准约定，其中添加了来自spring库的60个的附加模板函数以及其他专用函数specializedfunctions；

其中，所有模板文件都存储在chart的templates/文件夹中，当应用包管理中心渲染charts时，它将通过模板引擎传递该目录中的每个文件；

模板的值有两种提供方法：

1)在chart内部提供一个values.yaml文件；其中，该文件可以包含默认值；

2)在chart内部提供一个包含值的yaml文件；

当提供自定义值时，这些值将覆盖chart中values.yaml文件中的值；通过values.yaml文件提供的值可以从values模板中的对象访问，可以在模板中访问其他预定义的数据片段；

以下是values.yaml文件中的预定义值，其可用于每个模板，且不能被覆盖：

release.name：发布的名称；

release.time：应用版本上次更新的时间，这将匹配上一次发布的时间；

release.namespace：应用发布的命名空间；

release.service：处理发布的服务；

release.isupgrade：如果当前操作是升级或回滚，则设置为true；

release.isinstall：如果当前操作是安装，则设置为true；

release.revision：版本号，所述版本号从1开始，并随着每次升级增加；

chart：chart.yaml的内容；

files：包含chart中所有非特殊文件的map-like对象，不会允许用户访问模板，但会让用户访问存在的其他文件，可以用index.files“file.name”或.files.getname或.files.getstringname功能来访问文件，也可以用.files.getbytes访问该文件的内容[byte]。

s2、配置所述应用的应用包版本信息：

所述应用包管理中心的应用包版本管理单元将根据容器云应用包的版本命名规则来构建当前应用的应用包版本信息，每个应用的每个应用包版本都必须配置一个应用包版本信息，所述应用包版本的配置遵循semver2标准；容器云使用应用包版本信息作为应用的发布标记；应用包存储管理单元中的应用包由名称加版本信息进行存储和识别，如demo应用的version字段设置为2.3的应用包将被命名为：demo-2.3.tgz

s3、存储所述应用的应用包发布配置文件和应用包版本信息：

所述应用包管理中心的应用包配置管理单元和应用包版本管理单元根据对应的集成方法生成所述应用的应用包发布配置信息和应用包版本信息后，所述应用包存储管理单元将应用包发布配置信息和应用包版本信息存储在存储文件系统中；然后，将所述应用的应用包发布配置信息和应用包版本信息反馈至应用包发布管理器；

s4、根据用户发送的应用发布api请求，获取所述应用的配置信息和版本信息：

当进行所述应用发布时，所述应用包发布管理器接收到用户发送的应用发布api请求后，通过所述应用包管理中心获取所述应用的应用包发布配置信息和应用包版本信息；

s5、根据所述应用的配置信息和版本信息，获取所述应用的镜像信息：

所述应用包发布管理器确认获取到所述应用的应用包发布配置信息和应用包版本信息后，再通过所述应用包发布配置信息获取到所述应用的镜像信息，并发送所述镜像信息确认api至镜像仓库，所述镜像仓库确认该应用的镜像文件是否存储在镜像仓库中；

s6、根据所述镜像信息，查找所述应用的镜像文件；若所述应用的镜像文件存在，则反馈镜像文件存在信息给所述应用包发布管理器；若所述应用的镜像文件不存在，则触发应用管理人员制作所述应用的镜像文件，制作完成后，反馈镜像文件存在信息给所述应用包发布管理器；

s7、根据所述镜像文件存在信息，将所述应用发布至容器云平台：

所述应用包发布管理器确认应用镜像文件已存在后，将该应用发布至容器云平台中，并跟踪该应用的发布，直至该应用能够正常在所述容器云平台中运行；其中，所述应用发布的具体方法如下：

1)集群排出如下节点：

a.节点状态为不可用的“如节点不通或者容器服务运行异常等”；

b.节点剩余的cpu,内存资源不足以运行应用容器的；

c.容器运行时占用的宿主机端口出现冲突的；

d.按照节点选择label不匹配的；

2)在排除不符合的节点之后，剩下的节点均为候选节点；将所述应用具体调度到所述容器云平台的哪台计算节点上，由调度器的积分机制决定；

示例性的，节点a的打分将由如下公式决定：

finalscorenodea＝(weight1*priorityfunc1)+(weight2*priorityfunc2)+……

其中，有不同的评价策略以及其权重，每个节点获得的分值为节点按照各个评价策略及权重加和的值；

3)默认的选择策略包括以下几个：

a.leastrequestedpriority

打分标准公式如下：

cpu((capacity-sum(requested))*10/capacity)+memory((capacity-sum(requested))*10/capacity)/2

示例性的，cpu的可用资源为100，运行容器应用请求的资源为20，则cpu分值为8.0分，内存可用资源为100，运行容器应用请求资源为40，则内存分支为6.0分，则此评价规则在此节点的分数为(8.0+6.0)/2＝7.0分；

b.balanceresourceallocation

打分标准公式如下：

score＝10-abs(cpufraction-memoryfraction)*10

其中，cpufraction＝requested/capacity，memoryfraction＝requested/capacity

该调度策略是出于平衡度的考虑，避免出现cpu内存消耗不均匀的情况；

示例性的，某节点的cpu剩余资源还比较充裕，假如为100，申请20，则cpufraction为0.2，而内存剩余资源不多，假如为40，申请20，则memoryfraction为0.5，这样由于cpu和内存使用不均衡，此节点的得分为10-abs(0.2-0.5)*10＝7分；假如cpu和内存资源比较均衡，两者都为0.6，那么代入公式，则得分为10分；

c.calculatespreadpriority

此处的打分原则是：

score＝10*((maxcount-counts)/(maxcount))

这里主要针对多应用容器的情况下使用。

示例性的，一个web服务，可能存在5个应用容器，当前节点已经分配了2个容器应用了，则本节点的得分为10*((5-2)/5)＝6分，而没有分配应用容器的节点，则得分为10*((5-0)/5)＝10分，没有分配容器应用的节点得分越高，默认的各个调度的策略权重为1；因此，调度的结果为各个调度策略得分的和，然后按照得分进行排序处理；

4)通过如上的评判标准，容器平台积分制评价出各个节点的得分值，按照得分多少，将容器运行在最佳节点上；

在本实施例中，所述配置信息包括应用名称、应用镜像名称、应用资源配置、应用环境变量和目录映射配置、应用健康检查配置以及应用启动命令和启动的应用容器个数等。

在本实施例中，在步骤s1中，所述应用包版本信息的构建，遵循semver2标准。

本发明还提出一种基于容器云的应用集成和发布的系统，包括：

应用包管理中心，用于根据应用的配置信息集成所述应用的应用包发布配置文件，配置所述应用的应用包版本信息，并存储所述应用的应用包发布配置文件和应用包版本信息；

应用发布管理器，用于接收用户发送的应用发布api请求，根据所述应用发布api请求，从所述应用包管理中心获取所述应用的配置信息和应用包版本信息；

镜像仓库，用于根据所述应用的配置信息和版本信息，从所述应用包管理中心获取所述应用的镜像信息；并根据所述镜像信息，查找所述应用的镜像文件；若所述应用的镜像文件存在，则反馈镜像文件存在信息至所述应用发布管理器；若所述应用的镜像文件不存在，则触发应用管理人员制作所述应用的镜像文件，制作完成后，反馈镜像文件存在信息至所述应用发布管理器；

容器云平台，用于接收并运行所述应用发布管理器根据所述镜像文件存在信息发布的应用。

在本实施例中，所述应用包管理中心包括：

应用包配置管理单元，用于根据应用的配置信息集成所述应用的应用包发布配置文件；

应用包版本管理单元，用于配置所述应用的应用包版本信息；

应用包存储管理单元，用于存储所述应用的应用包发布配置文件和应用包版本信息。

在本实施例中，所述配置信息包括应用名称、应用镜像名称、应用资源配置、应用环境变量和目录映射配置、应用健康检查配置以及应用启动命令和启动的应用容器个数。

在本实施例中，所述应用包版本信息的构建，遵循semver2标准。

本实施例中的基于容器云的应用集成和发布的系统的工作流程：在用户进行应用发布前，所述系统会对所述应用进行发布配置信息的集成，同时触发应用包版本管理单元对该应用配置相应的版本信息，最后将应用的发布配置信息和版本信息集成后存储到存储文件系统中，完成应用配置文件的集成；在用户进行应用发布时，应用发布管理器首先会去应用包存储管理单元中查询应用的发布配置信息，获取到应用的发布配置信息后，再确认镜像仓库中该应用的应用镜像文件是否已存在，如果应用镜像文件不存在，则镜像仓库将触发应用管理人员进行应用镜像文件的制作，待制作完成后，反馈应用镜像文件存在信息给所述应用发布管理器，如果应用镜像文件已存在，则直接反馈应用镜像文件存在信息给所述应用发布管理器，此时所述应用发布管理器将应用发布至容器云平台的计算资源池中；至此，应用已发布完毕，应用正常运行在计算资源池内并对外提供应用服务。

以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的技术人员来说，在不脱离本发明构思的前提下，还可以做出若干等同替代或明显变型，而且性能或用途相同，都应当视为属于本发明的保护范围。