应用发布自动化如何落地到CMDB中去？

本文主要介绍设计与构建应用发布系统的第一步：如何 将应用落地到CMDB中？
本文系嘉为科技-罗杨原创。，商业转载请联系作者获得授权，非商业转载请注明出处。

一、背景

1.1 转型背景

应用运维的重要场景是应用软件的自动化发布，在数字化转型的大背景下，企业使用应用发布系统主要面临这几个问题：

1. 随着 业务线上化，业务量的快速增长，应用往往需要大规模集群的方式部署，加上对于业务连续性的要求，发布的工作量和复杂度成倍提升 。
2. 敏捷 、DevOps的新理念的流行，应用更新迭代速度加快。
3. 新技术 的不断涌现，迫使企业需要主动拥抱探索新型IT技术，应用技术百花齐放，如容器、微服务等 ，对应用运维提出了更高的要求。

1.2 标准化是构建应用发布系统的第一步

人工运维已经很难满足当前的发展趋势， 建设自动化运维成为了接下来运维工作的重点， 但是往往许多企业盲目的引进大量的工具去完成自动化，最终却会 发现工具用了一大堆，看起来好像降低了人手动的工作，可效率并没有提升，这种情况往往是因为没有把“标准化”这个基础工作先做好。

标准化的内容有很多，大到标准的发布方案、用全生命周期的标准流程，小到发布脚本、参数的标准化、应用名称的规范等。其中我认为最重要的也是最基础的是我们需要对应用这个逻辑的抽象有一个共同的认知，通过识别拆解业务系统并且在CMDB中描述。

二、如何有效管理应用

2.1 构建应用拓扑树

微服务的流行，分布式架构的日益成熟，往往我们 需要管理的应用系统数量是非常多，且在快速增加 ；你是否有过与产品同事鸡同鸭讲，一会儿是服务，一会儿是组件 的经历？你是否经历过突然某天应用重启命令无权限的情况？因为基础架构运维的同事把webLogic的用户调整了。如何有效管理这些应用及其使用的基础资源，统一命名、层级结构，是我们构建CMDB的目的。

我的思路是基于应用部署的视图拆分，基于“应用系统-环境-集群-模块”的模型对应用系统进行描述。

应用系统：

对外提供特定、完整业务服务的一组系统资源（软硬件资源）的有机组合，位于整个应用拓扑的顶层，例如：ERP系统、手机银行系统、英雄联盟系统。

环境：

指的开发测试环境、预发布环境、生产环境、灾备环境等。

集群：

大型应用系统一般会在多个地域机房部署相同的应用，如分布式架构下的北京集群、深圳集群；每一个集群可以独立提供完整业务服务。

模块：

最小化的功能板块，有许多相似的叫法：应用、服务、组件、模块等等，比如在电商系统下的订单模块、评价模块等等。

一般在传统应用架构下有几个特点：1. 没有把模块划得很细，2. 应用往往有独享的数据库、消息队列等基础资源，3. 应用架构相对简单，几台weblogic加上Oracle数据库就可以组成一个应用系统，所以这里的模块由应用模块和技术模块共同组成，如：报表模块、Oracle模块。

而在互联网架构下，往往只聚焦应用模块和业务功能。

2.1 应用与资源管理

我们知道CMDB主要还是以面向资源的管理，以资源的视角看CMDB是不够的，对于应用运维而言，我们希望以应用的视角看到全局。那么如何打通应用与资源的关系，我的思路是以模块为中心构建面向应用运维的应用配置管理。

部署配置管理：
对于应用发布而言，介质是我们绕不开的也是必须管理的对象，包括介质的下载地址、增量/全量类型、版本等属性。这里需要思考介质是否适合放在CMDB中管理，我从几个方面思考：
1， 介质 的消费场景是否通用？
2， 介质的信息准确性是否有技术或者管理手段保证？
综上思考，我认为介质的信息不应该放在CMDB中，介质的版本信息理应由制品库维护，并且只有在发布的场景中需要消费介质的数据，所以建议在发布系统中维护介质的管理信息。

应用拓扑管理：
即上一章节描述的应用拓扑模型，在CMDB中维护。

基础资源管理：
这也是CMDB最基础最核心的管理内容，以资源的视角看到IT资源的全景。我们可以通过关联的方式与模块进行联动，首先是主机资源，应用最终部署的目标还是主机，我们首先需要维护好应用与主机的逻辑关系。
当我们维护好了主机的关系后，就打通了业务与物理的关系，如何理解？基础资源都是部署在主机上的，应用拓扑是业务信息，当模块与主机存在关系后，就意味着应用与基础资源的关系打通了。

综上内容，我们可以以模块为中心，左边延展发布介质的信息，右边通过主机看到模块使用的基础资源内容，结合上边的应用拓扑，实现整个以应用为中心视角的IT资源视图。

三、发布场景与CMDB

我们将发布这个场景动作拆分成三个大的要素：发布目标、发布介质、执行操作；即通过“发布介质”在“发布目标”上执行“执行操作”实现发布场景，并且在发布时需要按照以模块为中心的原则执行发布动作。

我们将应用系统这一个抽象的概念通过结构化的描述落地在CMDB中，所有应用部门、运维同事都具备共同的语言与认知，我们可以清楚的知道我需要发布的目标是：电商系统的生产环境下广东集群的订单模块，我需要部署到订单模块下的A, B,C三台主机上，并且如果涉及到SQL发布的场景，我可以通过模块与MySQL实例的关系清楚的知道我需要在MySQL01这个实例上执行SQL脚本。

在发布系统上，我也维护好了一个关系：模块-介质，所以我在晚上12点脑子晕乎乎执行发布变更时，选择了订单模块时我只能选择与之关联的order_jar_v1.1.jar程序包，这样我就不会把隔壁购物车模块的包部署到订单模块的机器上。

更多：

高级发布场景：应用发布系统可以通过CMDB主机数据的消费，进行主机的编排，并行、串行、分批等，实现灰度、滚动发布等发布策略。我们可以通过编排模块之间的执行依赖，满足集群级别的灰度发布策略或者服务依赖场景的复杂场景。

联动监控/日志系统：如何验证发布的成功与否，除了业务上的验证之外，我们其实可以通过监控、日志系统进行发布前后的分析，那么如何联动发布系统、监控系统、日志系统呢？我部署了订单模块，我如何知道在日志系统中哪些日志是订单模块的？答案是 ：通过共同的语言实现多系统的打通。

四、总结

应用发布系统建设的第一个基础重点是标准化，我们需要先将CMDB落地应用的概念，并且以应用为中心管理应用的介质、基础资源等信息，为后续的应用发布场景提供准确标准的数据。