首页> 自动化运维> 应用发布自动化

[文章]应用发布自动化

收藏
0 24034 0

应用发布自动化

罗扬

【摘要】

本文主要介绍如何使用应用发布自动化进行高效的发布。

【正文】

   应用配置管理

1.1         什么是应用?

在物理上描述,应用应该是由一组应用程序和系统资源的有机组合。系统资源泛指中间件,数据库,负载均衡等。从业务逻辑上来看,应用是可以独立部署和运行,并对外提供业务功能。

对于企业来说,软件的在不断发展,用户需求爆炸式增加,软件功能不停的扩展,且迭代越来越快。同时在软件管理上,不同的操作系统,数据库,开发语言,数据格式等错综复杂,企业需要一种方法或者思想解决日益变化的局面。SOA,微服务架构就是其中的解决方法,而软件的服务化过程其实就是我们将完整的业务系统,切割成一个个具有不同业务功能的模块的过程,这些模块可以独立部署,相互之间通过固有的协议进行交互,对外提供相应的业务功能。

 

1.2         为什么以应用为核心?

企业传统的管理方式是针对基础架构的管理:存储,物理机,虚拟机,数据库,中间件,缓存,负载均衡等等。那么什么时候这台虚拟机会被创建,什么时候会被扩容,又什么时候会被销毁呢?我们可以得出结论,基础架构的生命周期由业务应用决定,基础设施的架构服务于软件架构——基础架构是为了上层的业务应用服务的。

当我们把业务系统按照业务功能拆分成一个一个的可以独立部署的模块后,运维就会异常复杂,尤其是当前互联网技术快速发展,微服务架构的流行,业务的爆破式发展,应用的复杂性急剧上升。所以我们需要围绕应用解决问题,急需要有一种方式可以管理模块之间,模块与基础组件之间的关系,并且在软件生命周期中这些关系是不断变化的。

可以想象一下这个管理的模型,我们希望能体现软件的业务架构,又希望能管理好支撑应用的基础组件。上层与底层的共同交集为模块,我们以模块为枢纽,向上构建应用的层次,向下构建应用资源,我们得到一个简单的模型:


                                   1 简单的应用模型

 

1.3         应用CMDB

运维的基石CMDB是以资源为核心的管理,当我们需要以应用为核心时就需要对于CMDB的建设有一定要求了,我们希望用一种通用的建设方式建设CMDB,他的设计能支撑多种应用架构,可扩展,支持不同的自动化运维场景。

按照图1的简单模型我们进行实际的落地,业务系统是具有独立业务功能的应用系统,如果这个系统十分的复杂,我们在管理时会把这个大的应用系统拆分成小一点的子系统。其次在软件的生命周期中,应用会在不同的环境中流转:开发环境,测试环境,预发布环境,生产环境等,在DevOps理念中,环境管理是至关重要的,持续交付就是用自动化的手段将开发好的软件包快速的在各个环境中验证。除此之外,在企业分布式系统中,一般会以地域划分不同的集群,各个集群提供的业务功能相同,比如说广东集群,北京集群,广东的用户优先访问广东集群。那么我们将应用模型完善一下,如图2


                            2 应用模型

       早期的基础架构运维关注基础环境的搭建,应用的开发一大部分精力放在购买主机,搭建网络设施等场景中,后来出现了Iaas,通过虚拟化技术让硬件资源能灵活使用,当然Iaas虽然解决了研发的一些问题,但是仍有不足,他还是以资源为中心,应用研发人员还需要考虑机器故障,网络故障,应用部署,监控,弹性扩缩容等。Paas应运而生,在Iaas上构建一层中间层,提供监控,运行,数据库服务,缓存服务等等。在这种场景下,应用所使用的资源不再由自身维护,如图3

      

                            3 应用模型

 

1.4         应用配置中心

我们有了CMDB为什么还要应用配置管理呢?我们可以看到上面的模型,是否还缺少一部分信息——应用的信息,CMDB终归是资源的管理,而应用本身的基础信息并不适合放在CMDB中纳管,比如说程序包,配置文件等,这些信息加上CMDB中应用资源的信息才是应用完整的数据,他的维护与建设支撑各种运维场景:持续部署,持续交付,监控,容量管理等等,那么我们就需要一个产品在CMDB的基础上管理应用的相关信息,并以此为基础支撑其他场景的数据使用。

应用配置管理Saas就是一款可以纳管应用配置信息的产品,他在CMDB的基础上进行扩展,纳管了应用的程序包,配置文件,进程,资源,主机,发布参数,为其他应用运维产品(应用发布自动化,应用巡检,应用启停等)提供数据。


                                          4 应用自动化运维产品总览

 

应用配置管理(后续特指的是应用配置管理saas)如何结合CMDB进行应用信息的纳管呢?如图5


                                   5 应用配置管理与CMDB

1.4.1       CMDB建设建议:

我们需要在蓝鲸CMDB中构建以应用为中心的应用层次拓扑,而绝不能着眼于资源对象,技术对象的维度划分,比如:Windows业务,Linux业务,而应该是电商业务,微信业务这样子的建设思路,服务树的末尾应该是模块,然后才是主机,而模型所使用的基础组件的资源通过CMDB模型的方式与之关联。

1.4.2       应用信息

1.4.2.1      环境配置:

在一般的开发流程中,应用需要经过开发环境—》测试环境—》预生产环境(或更多)的验证和测试之后,才能最终上线到生产环境,而在不同的环境中,应用的资源情况,配置信息都会有所差别,为了减少最终上线的风险,应用需要在类生产环境进行充分的测试。而面对这众多的环境我们需要将其纳管入CMDB中。

在蓝鲸CMDB中具有默认的三个业务拓扑模型:业务,集群,模块,业务与集群之间可以扩展模型,但是集群与模块的关系是紧耦合的,中间无法扩展,这样在落地客户的时候,根据客户的实际情况:是否有子系统,是否有环境,环境是放置于集群之上,还是放置于集群之下等等,这就需要我们能较为灵活的适配企业的情况,其中的重点在于环境的定义,如图6为一种CMDB应用层次模型,这个例子中的企业的应用层次为:业务——子系统——环境——模块,并没有集群,在落地时我们可以把蓝鲸CMDB中的集群模型作为环境。


6 CMDB应用层次模型

       在应用配置管理>系统管理>系统配置——环境配置中,我们可以定义那个CMDB的模型设置为环境:


7 应用配置管理系统配置

 

并且我们可以需要定义我们纳管的环境有哪些(实际为CMDB中环境模型的实例),用于切换,如图8


8 应用配置管理切换环境

 

1.4.2.2      资源配置:

我们清楚应用十分关注支撑他的基础组件资源,例如他使用了哪些数据库,负载均衡,中间件,消息队列等。在单体应用架构下,这些基础组件一般由应用自己部署纳管,而在微服务架构下,这些资源由PAAS统一纳管并提供给应用。所以应用与基础组件的关系存在两种,以MySQL举例:单体架构下:模块——主机——MySQL。微服务架构下:模块——MySQL

我们需要在CMDB通过模型进行纳管,举个例子:我们希望管理模块使用了MySQL,首先我们在CMDB中建立一个MySQL模型,并且在模块模型上添加与MySQL模型的关联关系:调用,如图9


9 CMDB资源模型关联关系

然后我们在图7的关联资源模型列表中添加MySQL模型,那么在‘应用管理-资源’中我们就可以根据这一个关系抓取到对应应用层级下所关联的MySQL实例了。


10 应用配置管理-应用管理-资源

 

1.4.2.3      程序包管理:

程序包,配置文件是应用重要的资源,我们需要对于他们进行纳管。在企业中,一般情况下运维与开发团队是相对隔离的,开发会提交一个可以部署的软件包,通过文件服务器或者其他的方式给到运维团队,然后运维团队在指定的时间段将一批应用部署至生产环境中,如果出现了问题需要回滚,可能通过备份的文件进行覆盖的手段回滚,也可以将旧版本的程序包进行重新部署,无论如何我们需要管理好程序包,配置文件的版本(制品库),以及应用与程序包的关系。

在应用配置管理中,我们将程序包与模块的关联来管理包与应用的关系,并提供版本文件管理的功能纳管程序包:


11 应用配置管理-程序包管理—详情

 

运维人员可以通过页面上传的方式上传程序包,但通常这一个手工操作是可以按照固定的流程自动化的,举个例子:运维人员每次都会去固定的文件服务器的某个固定目录下,拿到这个程序包的最新的文件:test-v1.1.jar,文件名按照某个规则定义了版本号。我们可以使用自动分拣功能自动化这个场景,只需要在标准运维中编排好:1,将开发上传包的文件服务器的固定目录中,将文件分发到应用配置管理的文件服务器上,2,按照文件名称的规则,获取版本号,2,回调应用配置管理的接口(传入版本号)。那么应用配置管理会自动识别到这个文件并且生成指定版本。

 

 

   应用发布自动化

2.1         简单的应用发布

应用发布是应用运维人员最重要的工作之一,应用运维工程师将应用的变更安全稳定的推到环境(主要是正式环境)中,其中最常见的发布是程序包的变更发布,我们举个简单的例子来看看在单体应用中单个应用的发布过程。

发布前:我们需要准备要要变更的程序包,准备好发布时的相关命令,比如停服务的命令,启动服务的命令。

发布时:

1,  登录到目标主机上

2,  把新的程序包上传到指定路径中

3,  备份一下旧的应用文件

4,  停止流量进入

5,  检查旧请求是否完成处理完成

6,  停止应用服务

7,  替换新的程序包

8,  重启服务

9,  最后验证服务是否启动成功。

发布后:访问一下站点是否状态码正常。       

这是其中一台主机的操作,如果应用部署在多个主机上,那我们需要在一台一台的主机上重复这些操作。在所有主机都操作完毕后,我们对于应用的可用性做一个检查,然后监控观察一段时间,最终没有问题才算是结束了这个应用的发布。

 

2.2         复杂的应用发布

随着分布式系统的推广,业务的发展,应用的发布会越来越频繁,软件的架构会越来越复杂,发布的场景也会越来越复杂:

1,  应用数量多

2,  应用发布频繁

3,  发布过程中要保证应用对外提供正常的服务

4,  应用之间可能存在依赖关系,必须先发布应用A后才能发布应用B

5,  发布过程中头疼的数据库变更

6,  如何保证发布的成功

要面对这样复杂情况时:

我们首先要做好标准化,如果同一个模块下的主机类型都各不相同,我们就需要花费大量的精力去适配,并且本身的复杂性就会导致发布中会发生未知的问题。

其次是做好应用配置管理,管理好应用,环境,程序包之间的关系,发布时需要使用的参数等。

然后是固化发布流程(这里的发布流程指的是执行流程,即2.1 简单的应用发布 中每个实例发布时执行的流程),如果每一个模块的发布流程都不相同,我们就需要给每一个模块都配置好一个发布的流程,这样就会增加发布流程的管理难度,如果我们可以将所有的发布流程进行汇总抽象,抽象成一个或几个发布流程,各个模块复用这几个流程,这样就可以大大降低我们管理的难度,也对发布流程进行了一次标准化。通常情况下,我们可以按照中间件的类别进行发布流程的抽象,Tomcat应用的发布流程可以规范成一种,WebLogic应用可以使用一种发布流程。当然还是会存在模块之间的差异,比如说同样使用Tomcat作为中间件,模块A的安装路径是/usr/tomcat/bin,而模块B的安装路径是/user/middleware/tomcat/bin,虽然发布流程上是相同的,但是里面执行的脚本会存在一些参数的差异,这样我们可以将这些参数抽离出来管理,将发布流程抽象成模板,在不同模块调用发布流程时,传入参数生成属于自身场景的发布流程。

关于发布流程的处理我们通过应用配置管理和标准运维来实现:

1,  我们使用蓝鲸标准运维进行执行流程的编排与管理,如图12是一个tomcat应用的发布流程模板,我们可以将一些不同模块下会变化的参数抽离出来,如图13


12 标准运维-流程模板


13 标准运维-流程模板—参数


14 标准运维-新建任务—填写参数

         在创建任务时,我们填写参数生成真实可执行的任务。如图14

         以上是标准运维的使用方式,他可以将发布的执行流程抽象成流程模板,并且提供执行的操作。

         2,众多的参数我们交给应用配置管理负责管理,首先我们思考这些参数是放在哪里管理的。我们认为模块与程序包的关系可能是多对多,一个模块部署着多个程序包,对外提供完整的服务;不同环境下的同一个模块共用一个程序包,或者这个程序包是公用的组件,提供给多个模块使用;这样对于发布的参数来说,我们定义在程序包与模块的关系上,如图1516


15 应用配置管理-应用管理-程序包

 

16 应用配置管理-应用管理-程序包-发布参数

        

        

2.3         发布策略

为了保证发布过程中,保证应用对外提供正常的服务,我们一般会使用不同的发布策略。

2.3.1       一次性全部部署(并行发布)

将应用下所有实例同时停止运行,并行更新版本,然后同时启动所有实例,这种策略在发布时不需要额外的资源,但是存在服务中断。

 

2.3.2       滚动发布

滚动的策略,设置停止实例的数量,例如1,意味着在发布过程中,先停止一个旧实例,更新完成后启动它,然后再更新下一个实例,这样就可以保证发布过程中服务不中断,也不需要额外的资源,但是他的缺点是发布需要的时间很长。

 

2.3.3       蓝绿部署

这种发布策略是为了解决滚动发布中,承担负载的实例数量减少,可能会带来未知的压力,蓝绿部署的方式是,先额外创建一批新的实例,并更新版本,然后将流量切换到新的实例上,由新的一批实例对外提供服务,在测试观察新版本没有问题后,将旧的实例销毁。这种方式意味着在升级的过程中,需要同时运行两套程序,所需要的资源是日常的两倍。但是这种策略的好处是,不中断服务,并且在发布过程中出现了问题,可以快速回滚。

 

2.3.4       金丝雀发布(灰度发布)

这种策略的做法是,先在旧的实例中,挑出少量的实例,将他们踢出负载均衡进行更新,然后将部分流量引导到新的实例上进行流量验证(金丝雀测试,灰度测试),保证新版本没有问题之后,将剩下的实例进程更新。这个过程就像,以前旷工开矿下矿洞前,先会放一只金丝雀进去探是否有有毒气体,看金丝雀能否活下来。

在金丝雀过程中就需要对流量进行筛选,通常我们可以使用nignx针对于IP,设备类型,浏览器类型进行流量的切割,针对于特定用户类型的流量,我们可以通过定制http请求头的方式进行条件的筛选。

 

 

 

2.4         使用应用发布自动化

2.4.1       快速发布

针对于单个模块的发布,我们已经定义好了发布流程(标准运维),管理好了模块与程序包的关系及发布用的参数,那么发布的过程自然轻松:


17 应用发布自动化-发布管理-快速发布

 

我们提供不同的发布方式:滚动发布和并行发布

滚动发布:针对于模块下的主机的发布实现滚动的策略,将主机进行分批发布。

并行发布:针对于模块下的主机进行并行执行发布。

 

17 应用发布自动化-发布管理-快速发布-滚动发布

发布时选择发布的模块,选择绑定到这个模块上的程序包及其版本,然后选择执行流程(标准运维),选择此模块上要发布的主机,如图17。发布过程中,会将相关的发布参数传递到标准运维进行实例化,每一台主机都会执行一次标准运维流程,应用发布自动化在上层进行调度。

 

 

2.4.2       批量发布

在多应用的发布场景中,应用之间的存在较为复杂依赖关系,应用A的接口依赖与应用B ,如果应用A先于应用B更新,就会造成逻辑的错误。应用发布自动化提供多应用编排的能力适配多应用发布的场景:


18 应用发布自动化-发布管理-发布任务

         我们可以定义了步骤与节点的概念,步骤是节点的集合,每个节点对应一个模块的发布,并且可以设置此节点执行完成后是否暂停(对应企业中审批或者人工操作的场景)。我们可以定义步骤的执行时间,步骤内节点的执行方式:串行,并行。步骤之间是否存在前置依赖。通过这样一个编排引擎,我们将企业中多应用发布的场景进行管理,并且在执行过程中提供丰富的人工控制能力:暂停,恢复,跳过,继续,终止,和过程监控,如图1920


19 应用发布自动化-发布管理-历史记录-详情

 

20 应用发布自动化-发布管理-历史记录-详情

 

 

 

 

 

 

 

自动化运维
最近热帖
{{item.Title}} {{item.ViewCount}}
近期热议
{{item.Title}} {{item.PostCount}}