嘉为蓝鲸助力某通信集团实现多类型应用发布自动化

01. 企业应用运维面临现状与痛点

根据IDC调研机构预测，2020~2024年，各类新开发的应用软件数量将达到5亿款，相当于过去40年的总和。

这是相当夸张的，对于应用运维人员来说，也意味着将遇到巨大的挑战，挑战主要来源于下面三点：异构、复杂和频繁。

应用的严重异构化，特别是随着微服务、云原生应用的大量衍生，加上终端和基础架构的多样性，又随着大家对于业务连续性和DevOps敏捷开发的重视度不断提高，随之带来下面关于发布的复杂和频繁的变更。

基于以上背景，需要对于应用发布平台提出的以下关键要求：分别是对于异构应用的支持，可支持混合部署，能提供高效稳定的海量节点纳管以及保证安全合规。

• 异构支持：能支撑单体、SOA、微服务、分布式、云原生等多种应用架构
• 统一部署：支持程序包、配置文件、SQL、容器的混合发布场景
• 海量稳定：提供海量节点纳管的能力，并且高效稳定
• 安全合规：与CMDB联动，保证变更可入库，与流程联动，保证变更可审计

02. 应用发布自动化的实现要点

要实现发布自动化，会有哪几点实现要点，这里总结了4点，分别是标准化、自动化、流程驱动和低入侵性。

标准化是第一步，其实不管是应用发布还是其他运维变更，想要做好自动化，首先就要做好标准化。

对于发布来说，标准化就包括发布流程、发布参数和发布操作等，还有就是最重点的应用标准模型。公司的业务、开发、测试和运维各个部门，对于同一套业务系统的架构理解，应该保持统一认识，否则自动化发布就无法顺畅开展。

第二点，自动化，这里涉及两个难点，即如何解决海量异构化应用和复杂发布场景。因此，需要有1个平台能够同时具有强大的管控能力和灵活的场景编排能力。

第三点，流程驱动，就是与企业的工单系统结合，实现发布工单的统一闭环管理。

第四点，保证发布平台的低入侵性，也就是发布平台的落地不能给业务团队带来较大的负担，尤其减少对业务侧代码改动的要求。

这里举了一个常见的应用代码与配置共同打包的例子，我们推荐的做法就是由发布系统直接管理配置文件，在发布过程根据不同的发布环境进行配置替换，无需应用做任何改动。

03. 某通信集团应用发布自动化案例

上述内容简单回顾了应用发布面临的现状以及要落地发布平台的几个要点。接下来，重点介绍下一个我们嘉为在某大型通信集团客户那里落地的应用发布自动化案例。

从背景、方案、场景和成果这第四个方面依次展开介绍。

1. 案例背景

1）客户痛点

• 节点规模越来越大（约6w台物理机），业务架构越来越复杂（全面转型微服务、容器化），传统手工变更发布的方式已无法支撑快速交付的需求。
• 部分产品在探索持续交付能力，但是没有形成统一的持续部署平台，无法统一管控应用部署变更。
• DevOps流程没有贯通，没有打通CD环节，业务迭代速度受到制约。

2）目标

• 面向公司全部集群和节点提供完整的持续部署流水线。
• 对接工单系统，实现变更集中闭环管控。
• 打通DevOps流程CD环节，实现业务快速迭代。

2. 方案

建设统一的发布自动化平台，对接工单系统、制品库和容器管理平台，实现所有发布变更的标准化统一管控。

• 主机应用发布：平台管理程序包、配置文件
• 容器应用发布：对接容器管理平台，实现灰度发布
• 对接分布式制品库
• 对接工单系统驱动发布

针对上述背景，嘉为蓝鲸与客户共同制定的方案是建设统一的发布自动化平台，对接工单系统、制品库和容器管理平台，实现所有发布变更的标准化统一管控。

平台核心是要具备应用配置管理能力、自动化能力以及第三方系统集成对接的能力。

上图是整体方案的逻辑架构，可以看到，发布自动化平台只是中间的这部分，但要真正实现发布自动化，离不开其他系统模块的支撑，包括前面工单驱动的发布源、提供程序包的制品库，后面自动化能力和容器管理能力，以及管理应用标准模板和操作对象的配置管理平台CMDB。

发布平台的功能架构如下，是围绕发布前、发布中和发布后三个环节，平台能力提供的编排、配置管理、发布执行和审计、以及检查验证的能力。

具体的项目落地分为三个阶段，分别是规划阶段、实施阶段和推广阶段。

• 规划阶段是我们和客户一起开展的，包括应用调研和发布规范的制定，用时两个月。
• 实施阶段周期较长，包括CMDB拓扑设计、试点系统测试环境使用、培训赋能和试点系统的生产环境上线。
• 目前正在持续推广中。

3. 应用场景

接下来看下平台场景的编排设计，发布场景主要有三类，分别是主机、容器和SQL类型，每一类发布变更，都可以在我们平台做编排设计。

根据现有的统计数据，主机和容器这两类的发布数据比例大概是1:3。

大部分的应用发布其实是混和类型的，就是容器+传统微服务应用，中间也会穿插数据库的SQL发布，但是发布思路相同，只要各种能力建设好，无非就是怎么编排发布的流程。

下面举两个比较简单常见的场景。

第一类是主机发布，这是一个多服务多节点部署的应用，应用架构师需要在我们的发布平台上编排好发布的流程，核心是执行的顺利和步骤，他可以不需要特别清楚了解具体每一个节点执行的具体操作，因为这个可以由我们的应用运维人员在标准运维上去做编排设计。

整个过程就是制品库获取制品-应用发布-标准运维-制品库制品分发-应用部署。

第二个场景就是容器灰度发布，操作分工和主机是类似的，区别在于应用发布获取的是制品库的镜像地址和yaml文件，然后调用容器管理平台的接口进行发布操作。

4. 案例成果

首先是应用发布平台为主体的成果，可以看到目前应用发布已经支撑14条产品线150+套应用14000+次发布任务，接入主机数为50000+，涉及近1000个程序包和300+个配置文件。近几个月月均2300次左右的发布量，一共完成了1300+发布变更工单。

这个数量级是非常大的，而且现在还在推广期，还有部分应用在持续介入。很难想象如果这些都通过人工去做会是多么大的一个工作量。

再简单介绍两组实际发布案例数据：

• 在去年7月份，我们的应用发布自动化平台支撑了客户一个大型的重要系统上线。涉及应用数量有20+，主机400+，脚本数1200+，发布任务数100+。
• 发布使用到现在，单个发布任务的规模和峰值数据：最大涉及服务数：100+，最大涉及集群数20+，最大涉及主机数2000+。

另外，围绕应用发布平台的建设，客户同时也使用我们蓝鲸的两个产品来辅助发布体系的建设，分别是容器管理平台和制品库。可以顺带看下这两块的建设成果：

容器运维平台目前已经纳管全网共300+k8s集群，集群节点总数5000+，命名空间9000+，通过API支撑着容器类型的变更以及支撑工单系统进行k8s集群资源申请的自动化操作，自动完成k8s集群的自动化创建全流程。

制品库目前已存入制品1.4w个，存储容量1.4TB，生产环境部署 1个主节点， 18个从节点，11个代理机，支撑多集群多应用同时调用。

最后，我们再一起看下这个案例给客户带来的收益总结：

• 技术先进性：CMDB纳管主机10W+，实例600W+，实现了对多类型软件发布支持、对海量节点的管控支持。
• 效率和质量：实现了DevOps、CI/CD全流程贯通，提升发布质量和效率，不仅完成对公司的应用发布流程进行统一管理，也计划将所有应用变更都利用平台做统一管控。
• 安全管控：实现对软件交付全流程统一管控，优化了跨部门协作流程。