一个产品服务的交付过程就像是在道路上行进，如果想要速度快，就需要有好的基础和好的工具。接下来由我来给大家分享一下我在 DevOps 落地建设方面积累的一些经验和教训，即：如何基于云服务打造一条 DevOps 持续交付高速公路，打通从代码到服务的通道，让我们的交付过程快速顺畅，通过实现快速可靠的部署和发布，提升研发、运维各环节的效率和整体的交付效率和质量。希望能在这里和大家一起讨论，共同进步，如有不正确的地方恳请大家指正，避免误导大家。
对于 DevOps，大家都不陌生，最近一段时间国内认同度和关注度也在持续上升，在各个技术媒体上关于 DevOps 文章和讨论非常之多，有很多非常好的从理论价值观实践层面讨论的文章。DevOps 最有标志性的文章就是 09 年的” Ten Deploys A Day ”，如果了解 DevOps，这篇是一定要看的文章。DevOps 和前些年的敏捷开发一样，对企业来说非常重要，是支撑企业业务创新的核心能力。今天，又有了云计算这个敏捷弹性自动化的 IT 基础设施，让 DevOps 平台的能力也有了一个巨大的飞跃。
本文将主要着重从云环境下的落地和解决方案的角度讨论，先和大家一起讨论我们为什么做 DevOps，将要打造 DevOps 高速公路的目标具体化；然后介绍一种能够在云计算环境下用最少的工作量、时间和代价风险落地的方案，基于云服务和云管理平台打造强大的横向纵向均全面覆盖环境和应用自动化的 DevOps 平台，实现在公有云、私有云、混合云以及传统数据中心中的各种业务应用的持续快速可靠的部署和发布，以及高效的运维管理。
一、为什么要做 DevOps，DevOps 要解决的问题
首先，我们先一起明确一下我们为什么做 DevOps，DevOps 要解决的问题，将 DevOps 建设目标收敛到符合 SMART 原则的具体的可达成目标。
从业务的层面，DevOps 要解决的主要问题就是实现从开发到交付端到端的业务敏捷，加速业务创新，缩短交付周期，实现持续快速可靠的交付；请见下图，来自于 AWS 官方资料，非常经典的一张图，清晰地诠释了 DevOps 的地位和作用。
具体到研发和运维的层面，DevOps 要解决的问题就是的交付周期长，发布不可靠、低效问题。
下面我们来层层剥茧，导出 DevOps 解决方案要实现的具体目标。对于交付周期长，发布不可靠问题，有很多影响因素，这些因素中，其中一个非常主要的因素就是：交付过程各个阶段中环境准备、部署发布环节手工操作多、速度慢、不可靠、没有规范。(请看下图)
(点击放大图像)
这张图展示了一个产品版本的整个交付过程，这个过程实际上就是一个不断修改代码、创建配置准备环境、部署应用，验证 (获取环境及应用信息，定位问题) 的循环过程。这个过程包含四个阶段，可以看到在每个阶段都需要经过多次创建或配置准备环境，部署应用的环节。这里的指的环境，不仅仅包含主机虚拟机、应用运行的操作系统环境，还包含中间件服务、防火墙、负载均衡配置、DNS 配置等。
在这个过程中对于我们研发团队面临和要解决的问题为：
- 在准备环境环节，通常在项目初始和过程中，由于需要向 IT 部门申请，不能够自助的获取项目环境所需的资源，导致不得不等待环境资源，影响交付的时间；
- 在部署应用环节，开发过程中需要部署测试时，由于部署的手工或半自动化，导致花费了大量的时间精力在手工操作和解决不可靠部署带来的问题上，特别是在集中集成测试阶段，当系统为分布式、组件比较多，涉及的机器数量比较多时，如果能实现环境和应用的自动化部署将会节省非常多的时间，缩短每次修改获得结果的反馈时间，从而加速开发过程；
- 仍然在部署应用环节，在日常测试场景中，由于创建一个环境比较麻烦费事，测试环境有限，所以经常出现由于测试环境有限导致不得不互相等待、协调，延误了问题的解决，带来很多管理和麻烦。如果能够实现创建环境自动化，那么当多人需要不同测试环境时，就可以按需自助创建，消除环境资源有限造成的瓶颈。
在这个过程中对于运维团队突出面临和要解决的问题为：
1. 发布过程速度慢，不可控、压力大，原因多由于：
- 手工或半自动过程
- 生产环境与开发测试不一致
- 部署方式不同
- 环境相关的应用配置文件没有很好的管理
2. 运维过程效率低，特别当环境很多、机器数量很多、系统为分布式系统时，分布在多地域多个云中时，需要经常扩容缩容时；
3. 当运维团队人数有限，有很多项目团队申请资源时，给运维团队带来很多工作量，造成很多压力。
对于以上的问题，基本可以通过环境和应用的自动化标准化解决，我们可以将要解决的主要问题具体到以下场景：
1. 实现环境创建自动化自服务
- 实现自服务 IT 功能让研发能够自助创建所需资源
- 对接云服务实现自动化创建资源
2. 实现应用部署自动化标准化
- 创建环境或新建虚拟机时自动部署
- 代码提交后的自动化部署
- 按需手动触发后的自动化部署
- 自动伸缩后的自动化部署
- 实现各个环境使用同样的脚本工具进行部署，最小化各环境部署差别为配置文件的区别
3. 实现编排全栈自动化
- 实现一键从无到有自动化创建部署环境并部署指定版本应用
- 实现一键添加指定用途虚拟机到环境并自动部署指定版本应用
- 实现定时或按需的一键扩容，自动添加虚机资源并部署应用，配置负载均衡,DNS 等
- 实现覆盖基础设施及应用的编排功能，并且能够跨主机、环境、公有云、私有云以及传统数物理及虚拟化环境编排
二、打造 DevOps 持续交付高速公路
针对以上的各个 DevOps 自动化场景，有很多实现的方式，包括基于容器的解决方案，由于容器技术当前还需要一段时间才能“飞入寻常企业家”，较大范围的应用到生产环境，对当前的开发和运维管理习惯改变比较大，相关配套设施也要求比较多，所以这个后续再表。现在，先给大家介绍一种基于 IaaS 云服务和云管理平台的比较容易落地的 DevOps 平台解决方案，供大家参考。通过这个解决方案我们能够以很小的代价，快速地基于公有云私有云服务实现开发测试以及运维中的各种环境和应用的自动化，能够非常容易的落地，对应用的架构没有限制及对现有代码无侵入。从实现的代价工作量来看，根据对以往经验，对于 20 个项目，平均一个项目 4～5 个组件，考虑项目的基础条件不一样，综合平均下来每个组件的实现代价小于 1.5 人天。
(点击放大图像)
这个平台解决方案如图示，主要由三大部分组成：一个是配置管理部分，一个是云管理平台部分，一个是定制化应用部署工具部分。这个方案有几个关键的选型和设计：
选择了云管理平台，原因如下：
由于云管理平台本身集成了各个 IaaS 云服务的 API，相比于直接基于云 API 开发自动化功能，或编写环境自动化的模板文件，能够让我们免去大部分集成 IaaS API 的二次开发工作，降低了实现自动化的开发维护工作量和门槛，同时能够充分发挥云的自动化特性；
云管理平台提供了业务角度的管理视图，对虚拟机按照用途和环境类型进行分组，符合我们管理操作的习惯，可以可视化的一目了然在一个集中的视图中，先按用途找到机器具体信息，然后再进行相关操作，让我们不需要再采用之前使用 Excel 表手工维护管理环境信息；
云管理平台提供了集群感知和编排的功能，能够让我们实现一键创建环境虚拟机并自动部署配置应用的功能，应用到开发测试过程中建立测试环境场景，以及诸多运维场景，如一键扩容缩容、自动故障恢复、备份恢复等等，还有包括公有云、私有云、虚拟化多种环境中；
云管理平台提供了一体化的工具，涵盖了环境管理、批量管理、代码部署、监控告警等功能；
云管理平台不同于 PaaS，不对应用的运行环境进行限制，所以可以广泛的用于实现各种架构的应用的自动化部署，而不仅仅限于 Web 类的应用；从管理对象上，云管理平台不仅可以对接管理各个主流公有云私有云的虚拟机，而且还可以将传统物理机和 VMware 虚拟机导入进行管理，既能够管理各个遗留环境中应用，也能管理运行在 IaaS 上的应用，在遗留环境自动化部署后，还能够实现应用的上云迁移。
(点击放大图像)
应用自动化部署采用AWS CodeDeploy 规范
AWS CodeDeploy 源自 Amazon 内部一个非常成熟的规范，这个规范适用的范围很广，对应用的部署架构没有限制和约束。而且非常易用易于掌握，便于落地和推广。对于部署规范的选型非常重要，直接决定了是否易于推行实现和工作量。
(点击放大图像)
下面我们具体介绍一下各个部分，然后以提交代码自动部署场景和一键自动创建虚拟机并部署代码为例介绍DevOps 场景的实现过程：
1. 配置管理部分
主要由版本控制系统、持续集成服务、制品库服务组成。这部分的主要作用是，能够将要部署的代码自动编译，并进行必要的单元测试和组件测试，将部署包上传到制品库并将版本信息注册到云管理平台，存储并管理部署包，为后续的自动化部署提供可下载的部署包，方便实现自动化部署下载版本代码，给自动化部署打下一个好的基础。即便代码存放的版本控制库不一样，所处的网络不一样，仍然可以用统一的 HTTP 方式下载，也方便同步部署包到各个不同地域网络以保证下载速度。
这部分输入为开发人员提交到指定分支的应用代码，输出为制品库如 Nexus 上的应用版本部署包和云管理平台上的应用版本信息。
中间的实现依赖于 Jenkins 和 Maven，每个需要独立部署的应用的代码分支，在 Jenkins 上都对应一个 Jenkins 持续集成任务，当代码提交后，那么这个对应的 Jenkins 持续集成任务就开始同步分支最新代码，并编译，单元测试，通过后使用 Maven 进行打包并上传到制品库如 Nexus，之后调用定制的 Jenkins 插件将部署包版本信息注册到云管理平台上。
2. 云管理平台部分
云管理平台在整个方案中的作用是：
- 在环境准备场景中，可集成各个主流公有云私有云 API 创建虚拟机，对通过集成云 API 自动创建和纳管，进行分组分类管理，提供业务维度的管理视图；
- 在部署应用场景中，提供应用版本信息的管理，以及自动化部署引擎，支持符合 AWS CodeDeloy 规范的应用部署包的部署，实现部署的标准化自动化和可视化；
- 提供编排自动化、批量管理以及基础设施感知功能，支持实现应用的各种场景下的自动化部署，如创建虚拟机时，提交代码，手动触发，执行编排部署任务、定时或基于监控的自动伸缩，备份恢复，自动故障处理等；
- 提供自服务 IT 功能，能够让研发人员在 IT 允许的范围内自助获取资源准备环境；这个能有效解决在获取资源环节上研发和 IT 的协作问题，既减轻了 IT 的工作量和沟通成本，也提升了双方的效率。
(点击放大图像)
3. 定制化应用部署工具部分
这部分的主要作用是，遵循 AWS Code Deploy 规范，将依据规范实现的各个步骤的部署脚本与应用代码打在一个包内，部署引擎下载应用版本代码到要部署的主机后，会按照规范配置执行这个部署各个步骤的脚本，完成应用在主机上的自动化部署过程。
上面给大家介绍了 DevOps 平台解决方案的组成部分，下面以两个典型的 DevOps 场景给大家介绍一下实现的原理：
- 代码提交后自动部署 DevOps 场景实现过程：
- 开发人员将某应用代码提交到其某个分支上；
- 应用分支对应的 Jenkins 任务自动被触发，开始同步分支最新代码，并进行编译，只会调用 Maven 打包并上传到 Nexus；
- Jenkins 任务调用云管理平台应用代码部署插件将应用版本信息注册到云管理平台；
- Jenkins 任务调用云管理平台应用代码部署插件通知云管理平台将应用版本部署到指定范围的主机上；
- 云管理平台将部署请求下发给主机上的 Agent；
- Agent 收到请求后下载部署包，解压后，按照 CodeDeploy 规范，执行部署各个步骤的脚本进行自动化部署，同时将执行的日志和结果上报给云管理平台控制台，完成代码提交自动化部署。
- 一键创建环境主机并自动部署 DevOps 场景实现过程：
- 创建虚拟机创建模板，设定对虚拟机配置、操作系统、网络，负载均衡，以及虚拟机启动后要执行的脚本等要求；
- 指定使用虚拟机创建模板创建虚拟机并添加到指定的环境的主机组中；
- 云管理平台根据虚拟机模板请求调用云 API 进行创建；
- 虚拟机启动后，云管理平台使用 SSH 自动登录到虚拟机安装 Agent；
- 云管理平台通知 agent 部署应用；
- Agent 将部署包下载到其所在主机，然后依据包中部署规范配置自动部署应用。
这里有一点需要说明的是，自动化部署是持续交付里最基础的第一步，做到这一步能够大幅提高效率，但是要想实现持续交付，还需要有比较完备的自动化测试工具，实现各个层次阶段的测试，包括持续集成阶段的单元测试、组件测试，部署后的集成测试，运行期的实时监控。对于自动化测试的实现，通常是一个比较大的技术债务，最好在项目的研发过程中实现，否则最后很难有获得专门的时间投入资源去做。
最后，总结一下，本文的要点有三：
- 了解 DevOps 要具体解决的自动化场景
- 了解上云后基于云管理平台能够易于且快速落地的 DevOps 的解决方案
- 了解云计算环境下用最少的工作量、时间和代价落地的 DevOps 解决方案
通过这个方案：
-
实现各种场景的环境和应用的自动化，自动化部署升级发布，从而有效地支持开发测试进行高效的开发测试，减少过程中不必要的资源等待，手动操作，缩短反馈周期提交效率；
-
帮助运维实现快速可靠的发布，支持研发和运维在申请资源环节和发布环节的高效协作；
-
帮助实现从敏捷开发到交付的端到端业务敏捷。
精彩 QA 环节
问：在 DevOps 的环节中，QA 如何发挥作用？
刘涛：发挥作用体现在两个环节，一个是各个阶段的自动化测试，一个是不能或暂时不适合自动化的人工测试。
对于自动化测试，在持续集成阶段的贡献为单元测试、组件测试，帮助快速完成新加功能的测试以及验证是否影响已有功能；对于部署后的集成测试阶段，完成必要的人工功能性测试保证上线的质量。
自动化测试越完备，对快速开发交付贡献越大。
问：DevOps 是以运维为主，还是开发为主, 现在可以使用云上提供的各种 API，将来运维何去何从？
刘涛：我一直最大的感受是，从实现 DevOps 所做的云服务至上的自动化工作上更多依赖于开发，而云服务的稳定性维护和提供必要的支持和工具还依赖于运维。云计算给运维工作带来的改变是非常大的，提供了一个弹性自动化的基础设施服务，运维将来的发展方向也会在这个基础上越来越自动化，越来越智能化。
问：近来容器潮席卷技术社区，我想问下，老师怎么看待 DevOps 与 Docker 结合解决痛点？
刘涛：对于 DevOps 与 Docker 结合的痛点，我觉的主要在于网络的方面，这个影响会具体会影响到应用的自动化的部署上。之所以有这么多的容器解决方案，有这么多的编排方案，网络方案，都是要解决连接问题。
现实中非常多的应用的架构并不是一个简单的架构，而是分布式的，要想让适用于大多数分布是应用的部署，首先要解决网络层的连接，然后是各个应用组件的连接配置。
问：跨云管理与持续交付的难点在于哪里？您今天分享的方案是否使用此类场景？
刘涛：这个问题非常好。
跨云管理的难点在于管理的覆盖面和编排上，可以从几个维度上看。
- 一个是纵向的覆盖面，需要既覆盖基础设施层，也覆盖应用层，而基础设施层需要覆盖资源的类型又有很多种，要想做到比较全面的覆盖是一个很有难度的事情。
- 一个是横向的维度，这个横向的维度就是跨云、跨网的编排，要做到这一点需要处理非常多的异构情况，同时要想跨网，需要在管理的设计上做一些特殊的处理。
- 对于持续交付的难点上，我觉的最大的难点不在于自动化和部署上，最大的难点在于能否在做到自动化部署发布之后的测试上。
如果在整个开发过程中，能够比较好的做到自动化测试，加上完备的手工测试，才能真正做到持续交付。一个极端的例子就是，虽然实现了自动化的部署，但是部署后，如果没有比较好的自动化测试，仍然将不得不花费很长的时间进行验证，才能真正完成部署上线。
关于作者
刘涛，目前在 FIT2CLOUD 从事云管理和 DevOps 平台的研发工作，曾在 InfoQ 和 CSDN 发表过《国内云建设普遍缺失的一环：云管理平台》，《剖析 AWS CodeDeploy》，《亚马逊 AWS 认证攻略》，《DevOps 系统的变迁及其关键使能技术》等文章。职业生涯的主要角色基本都在研发，也常常负责自身研发的产品服务的运维管理，经历过传统物理环境下的大规模移动互联网服务的研发运维，也经历过云环境混合云下的研发和运维，深切地体会到云计算给我们研发和运维工作方式带来的改变，效率上的巨大提升。
感谢魏星对本文的策划和审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论