「云端的 DevOps」系列之大话 DevOps 解决方案变迁

前言

最近 Puppet 和 RightScale 相继发布了 DevOps 2016 报告，其中 Puppet 的报告侧重于 DevOps 的价值 ROI 的调查结果，用调查结果佐证了DevOps 给企业研发生产力和质量带来大幅的提升。 RightScale 的报告则侧重于 DevOps 的接受度和 DevOps 工具的采纳使用情况，特别是 Docker 的采纳接受度，结论是Chef 和 Puppet 依然是最常用的 DevOps 工具，Docker 接受度出现大跃进，对 Docker 的接受呈现出野火燎原般的发展趋势。但是对于 RightScale 给出的 DevOps 的工具的调查，主要局限于传统配置管理工具 Chef、Puppet 和 Docker 等工具调查上，仅仅以 Chef、Puppet、Docker 等来涵盖 DevOps 的工具采纳上，还是有些局限。

图 1 DevOps 平台

如今，企业上云使用云已是常态，云计算和容器从基础设施层面进一步解开了研发运维的枷锁，除了传统的配置管理类型诸如 Puppet、Chef 等 DevOps 工具，也出现了多种其他类型来源的 DevOps 工具和解决方案，大多都面向和基于云基础设施和容器以最大限度的提升 Dev 和 Ops 的效率，加速业务创新。接下来我就在这里抛砖引玉，谈谈我对 DevOps 解决方案的理解和看法，和大家共同探讨 DevOps 解决方案的过去、现在和未来，探讨当前的解决方案，我们需要的是怎样的解决方案，理想中的解决方案，希望能引起大家的思考。

DevOps 也和敏捷一样，由文化、实践、方法和工具组成，从理念到落地并非易事，同样也需要工具的支撑，这里我们着重讨论工具层面的方案，先从 DevOps 的定义入手，从定义上看从最初提出到现在内涵和外延上的变化，然后一起讨论下 DevOps 解决方案的几种不同来源、类型和特点，从传统静态基础设施到云可编程弹性基础设施时代的变迁，之后谈谈理想和现实，谈谈那些年我们用过的产品、工具和玩具，得到的教训，谈谈当前常见的 DevOps 解决方案，以及理想和现实的差距。

一、DevOps 定义及变化

以下是 Wiki 上 DevOps 的定义:

DevOps (a clipped compound of development and operations) is a culture，movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.It aims at establishing a culture and environment where building，testing，and releasing software can happen rapidly，frequently，and more reliably.

翻译成中文:

DevOps(英文 Development 和 Operations 的组合) 代表一种文化、运动或实践，强调在软件交付和基础设施变更过程的自动化，以及过程中软件开发人员 (Dev) 和 IT 运维技术人员 (Ops) 之间的合作和沟通。它的目的是构建一种文化和环境使构建、测试、发布软件更加快捷、频繁和可靠。

以上 Wiki 的定义清晰地阐述了 DevOps 的目的、要解决的问题以及包含的内容。这个定义的内涵和外延从最初提出到现在还是有变化的，变化的主要点在于基础设施变更 (infrastructure changes) 这个部分。在最初提出 DevOps 概念时，在传统静态基础设施时代，由于受限于基础设施的静态局限性，变更基础设施仅指静态的主机虚拟机准备好之后，对应用运行环境主机 OS 进行的变更配置管理，而在云计算时代，这个部分，不仅仅指应用运行环境 OS 的配置管理，还涵盖了基础设施云资源生命周期的管理，比如虚拟机等资源的创建释放等。

那么接下来，我们一起看一下 DevOps 解决方案工具链和 DevOps 工具及解决方案的变迁。

二、DevOps 解决方案工具链

以下是 Puppet 给出的 DevOps 工具链 ( 5 Pillars of the DevOps Toolchain )

• Version control (GitHub、Mercurial、Perforce、Subversion、Team Foundation Server)
• Continuous integration (Atlassian Bamboo、Go、Jenkins、TeamCity、Travis CI)
• Configuration management (Puppet and others)
• Deployment (Capistrano、MCollective [part of Puppet Enterprise])
• Monitoring (New Relic、Nagios、Splunk、AppDynamics、Loggly、Elastic)

Puppet 将 DevOps 工具链分为 5 个部分，版本控制、配置管理、持续集成、部署和监控，并给出了每个部分可选的工具。尽管 Puppet 在 Puppet Enterprise 里加入了对云服务如 AWS 的支持，但是从工具链上看，由于没有将 Provisioning 基础设施自动化和部署后的环境应用管理单列出来，仍处于传统的配置管理思路上。而在基于云的 DevOps 工具链中，除以上工具外，还引入了环境创建 (Provision) 以及部署之后的应用生命周期管理部分。以 AWS 的工具链为例:

图 2 AWS DevOps 解决方案

我们看到相比传统的 DevOps 工具链，AWS 的 DevOps 解决方案增加了 Provision 这个部分，在 AWS 这个部分有 CloudFormation 产品，用于基于一个定义的环境模版从无到有完成环境的创建，包括虚拟机、网络、存储、RDS 等。

以上我们从 DevOps 的定义内涵外延以及工具链整体上分析了 DevOps 解决方案的变化，接下来我们具体分析一下这些内在变化以及这些内在变化给外在 DevOps 解决方案输出的能力上，给 Dev 和 Ops 以及组织在各个场景中效率带来的影响。

三、云时代 DevOps 解决方案的变迁

DevOps 解决方案的核心能力在于规范和自动化，基于规范和自动化就能够为 Dev 和 Ops 提供面向各种场景的工具和服务，自内而外极大提升 Dev 和 Ops 各自的效率以及之间的协作效率。对于 DevOps 解决方案的变迁，我们从上面工具链的变化能够看到，在版本控制、持续集成这两个部分没有差别，最关键的变迁在于之后的环境与应用自动化部分: 从 Configuration Management 扩展为 Infrastructure Automation，从 Application Deployment 扩展为 Application Lifecycle Management。

具体来说就是，从局部仅涵盖静态基础设施手工准备好之后的静态配置管理、应用部署交付，转变为实现了全方位的资源环境动态编排自动化及应用自动化，自动化范围纵向上既涵盖下层资源环境也覆盖上层应用，横向上涵盖面向物理机、虚拟化、公有云、私有云各个基础设施环境资源及应用发布和管理，管理过程范围涵盖资源和应用的整个生命周期。

图 3 DevOps 解决方案自动化涵盖范围变化

图 4 局部自动到全方位自动化

1、从局部自动化到全栈自动化

从局部仅涵盖静态基础设施手工准备好之后的静态配置管理、应用交付，不涵盖资源自动化创建管理，转变为实现了涵盖下层资源环境及上层应用的整体动态编排自动化。

2、从应用局部生命周期到资源应用全生命周期

传统 DevOps 解决方案仅管理局部，即静态基础设施手工准备好之后的静态配置管理和应用部署交付，没有涉及应用部署后的生命周期管理，如故障恢复，弹性伸缩以及资源管理等，到了基于云的 DevOps 解决方案，则扩展到包括资源环境在内的资源和应用的全生命周期管理。能够一键创建环境及应用，完成从无资源无环境到包括资源环境应用在内的全栈自动化以及之后的监控、自动化故障恢复及弹性伸缩管理等。

这里有必要说明下环境所包含的内容，这里我们所说的环境，不仅仅包含通常的虚拟机、虚拟机承载的 OS、OS 中安装的运行时环境，还包括中间件、防火墙设置、负载均衡设置、DNS 配置等。

3、提供上下文事件驱动编程接口

基于云的 DevOps 解决方案，往往提供多种事件驱动的接口以可以实现基于手工触发的、时间的、资源变化的、监控变化的事件的自动化处理，从而实现开发运维多种场景的自动化。比如云管理平台 Scalr ，Scalr 能够基于云的 API 实时了解资源的情况，Scalr 提供了虚拟机生命周期事件接口，可以设定当虚拟机创建、重启或释放触发在指定范围的虚拟机执行脚本，借助这个事件驱动编程接口，我们就能实现从无到有创建整个环境并部署应用，也能实现一键扩容时完成虚拟机创建及应用部署，实现自动获取虚拟机 IP 信息进行动态的应用连接配置，实现自动故障处理等。这个功能能力是衡量诸多 DevOps 方案的一个非常关键的能力。

4、支持 IT 资源获取环节的 Dev 和 Ops 协作

由于传统物理机虚拟化时代基础设施为静态基础设施、使用审批以及手工创建方式，所以传统的 DevOps 解决方案并没有覆盖 Dev 和 Ops 在资源获取环节的协作。经常出现的问题就是，Dev 经常需要等待 IT Ops 提供资源，并且经常出现沟通的不一致问题，导致在 Dev 创建环境这一环节往往需要数天甚至数周的时间。到了基于云的 DevOps 解决方案，由于有了自动化可编程的基础设施，因而能在此基础上提供自服务 IT 的功能，能够让 Dev 人员在允许的额度和限制范围内自助获取资源，减少了很多与 IT Ops 的沟通的时间和问题，也减少 IT Ops 的工作量。

可以说，以上 DevOps 解决方案几个方面的变迁对开发测试及运维业务场景的影响上非常大，下面我列了一个表格，比较了开发测试和运维中使用 DevOps 解决方案能力上的差别。

图 5：传统 DevOps 解决方案和云 DevOps 解决方案能力比较

以上我们具体分析了 DevOps 解决方案的变迁和对 DevOps 能力的影响，当前 DevOps 解决方案有很多，但是各有各的特点、优缺点和适用的范围，接下来我们看看常见的 DevOps 解决方案的类型和特点。

四、常见 DevOps 解决方案的类型和特点

当前 DevOps 解决方案主要来自于五种类型的公司：云服务提供商、云管理平台公司、传统配置管理类型、Docker 公司、大型互联网公司。

图 6 DevOps 解决方案分类

尽管云计算提供了弹性可编程的基础设施，但是当前的各种 DevOps 解决方案各有其特点和局限性，同时也均有非常大的改进空间:

• 传统的开源配置管理解决方案：仍然专注于静态基础设施思维下的配置管理，在环境自动化，应用自动化方面均不够好，与各个云的对接支持上，产品化上易用性上均需要提升；比如 Puppet，尽管提供 Puppet Enterprise 解决与云基础设施服务的对接，但是对接上与云管理平台对各个云服务的对接上相比相距甚远；
• 云服务提供商的解决方案：云服务提供商自身提供的 DevOps 解决方案又多出于锁定用户角度目的设计，仅仅适用于其自身云服务，对其他云各种公有云、私有云以及国内本地云服务缺乏支持；比如 AWS 提供的 DevOps 工具，只能在 AWS 云服务范围内使用，无法在其他公有云私有云和传统虚拟化及物理机环境下使用。
• 传统 PaaS：对应用架构有限制和侵入，落地困难，选择时需要明确要管理的应用的架构是否仅为 Web 类型进行慎重选择。一个事实是，尽管云计算和 PaaS 发展多年，但是迄今为止，当前大多数上云的应用和平台仍然直接运行在 IaaS 上，而不是在 PaaS 上。
• 云管理平台解决方案：在云的对接上往往比较广泛和易用，提供以应用为中心的管理视图，对应用的架构没有限制和侵入，易于落地，但是在应用管理方面支持相对缺乏和单薄，需要基于其提供的事件驱动编程接口设计方案，定制开发，比如 Scalr。
• 基于 Docker 的容器云解决方案：容器云是是目前市场上解决方案最多最热，由于容器的轻量、标准化和可移植性，这一点给应用在异构资源池中的部署提供了统一的标准和接口，相比基于传统虚拟化基础上的 DevOps 方案，容器云更容易实现在同构异构 IT 资源池环境中快速部署，发布、迁移、扩展，以及防止供应商锁定，同时能极大地提升资源利用率。容器云是当前和今后的热点，但是对研发运维原有的使用习惯改变不小，需要较全面的支撑工具，当前产品化上仍然不够，使用起来还有有不小的门槛，需要较强的技术能力。还有一点就是，不适用于传统已存在应用和主机的纳管，只能管理通过容器云启动的容器之上的应用。
• 互联网公司解决方案：比较典型的是 Netflix 开源的 Spinnaker 。对于 Spinnaker，可以借鉴 Spinnaker 的思路和设计，一个是对部署流水线的过程和可视化支持非常好，另一个是管理的维度分为集群管理和部署管理，对资源以应用为中心进行逻辑上的划分非常直观和清晰和符合管理习惯，但是由于 Netflix 是重度 AWS 用户，所以其内部开源出来的和 AWS 的绑定很深，不太适用于其他公有云、私有云，另外就是作部署前需要先做镜像，这个还是有些重，做镜像非常耗费时间，在集成阶段需要不断修改和获取反馈时不太合适。

五、理想中的 DevOps 解决方案

尽管时代在发展，各种 DevOps 工具也一直在发展，但是当我们每天在工作中在使用现有工具，在各种基础设施环境中创建环境和部署管理应用时，仍会遇到很多当前工具没有解决的问题，不适用的场景，导致我们不得不花费很多的时间精力在沟通、靠手工弥补、定制化的开发、解决方案的设计上，即费时又费力，关键是效率很低，浪费了很多可以通过工具来节约的时间。

那么我们期待的 DevOps 解决方案、产品是什么样的？

1、支持各种公有云、私有云及各种基础云资源

看过用过许多 DevOps 的工具，特别是一些开源的工具，要么不支持与某些云的对接，要么支持多为需要二次开发编程配置，对于云资源和应用的管理，我们需要一个广泛支持各种公有云私有云且易用的工具，能够让我们快速简单的创建环境和部署应用，减少手工二次开发和配置上浪费的时间和不便。

2、支持已有主机应用的纳管

当我们要将 DevOps 落地时，不可避免的会碰到现有正在开发中项目，对于这些项目，一方面往往主机等资源已存在，应用已部署并在运行中，另一方面，架构基本已定，很难会为 DevOps 自动化部署进行架构上的调整，对于这种情况而言，对应用架构有要求的，比如需要以微服务架构而基础的，只能管理通过 DevOps 管理平台启动的主机或容器的方案就不适用了。我们需要一种对应用架构无侵入对已有代码无修改的 DevOps 管理平台，一种能够对已启动主机进行纳管的平台解决方案，才能够落地。

3、无侵入支持各种架构类型应用和平台

这一点非常重要，DevOps 平台首要的就是能够部署和管理应用，且能够易于落地，支持现有的项目、近期的项目实现 DevOps，如果对应用的架构上有限制和要求，则很难落地和实施。另外，其实平台本身也是应用，比如云平台本身、PaaS 平台、容器云同样也需要管理，如果管理平台也支持物理机或虚拟机之上的这些平台本身的管理，这样的管理平台 DevOps 解决方案无疑是最强大的。

4、开放的平台

• 提供事件驱动可编程接口，能够手动按需、定时、基于监控、基于代码变化、API 进行响应自动化处理 ;
• 提供云平台支持可扩展接口，能够以插件方式支持各种不同的云 ;
• 提供 HTTP API 扩展接口，能够基于 API 进行扩展和集成。

5、产品化且易用

看过用过需要 DevOps 的工具，特别是一些开源的工具，灵活性和扩展性都不错，但是在易用性上，学习和使用的门槛上，还是有很大欠缺，如果能够更加易用些、更加产品化一些将能节省更多的时间，让更多的人更快地用起来。

6、一体化的平台

在研发和运维的过程中，不仅仅需要快速可靠部署的发布，还需要对业务系统整个生命周期的管理，包括资源环境信息、分组分类、环境管理、权限管理、部署发布管理、批量管理、告警监控、伸缩管理等，希望能有这样比较全面的管理平台，而不用再东拼西凑拼接解决方案，再花费精力二次开发打通各个管理工具。

7、支持全方位的自动化编排

企业在上云的过程中，我们的业务系统，应用分布在传统数据中心和私有云、公有云中，希望能够一个 DevOps 平台在纵向支持下层资源和上层应用的全栈自动化编排，横向上能够支持跨传统 DC、私有云、公有云的任务编排，包括对资源任务、对脚本任务、对部署任务的编排，这将使得我们能够在很多场景如灾难备份恢复、扩容缩容、部署升级发布，极大地提升自动化的程度和效率。

8、支持通用易用易于落地部署规范

如果有一套通用易用易于学习落地的部署规范，则 DevOps 的落地，在组织范围层面的落地会变的更容易一些。

图 7 理想中的 DevOps 解决方案

六、总结

云计算从基础设施层面实现了敏捷 IT，进一步解开了研发运维的枷锁，使得 DevOps 解决方案也有了长足的发展，使得其所能提供的 DevOps 能力有了一个飞跃，实现了涵盖资源环境在内的应用全栈自动化，并基于强大的自动化能力，基于事件驱动的环境创建管理自动化、应用生命周期管理自动化，为开发测试和运维各个场景提供高效的管理工具，比如一键编排创建开发测试环境，批量管理、应用部署、自动故障恢复、备份恢复、自动伸缩、自服务 IT 等，极大地提升了 Dev 和 Ops 各自的效率以及在部署发布环节和获取 IT 资源环节协作的效率，实现了从敏捷 IT 到敏捷开发再到敏捷运维的端到端的敏捷。

然而，尽管云计算和容器提供了非常好的基础设施，但是现有 DevOps 解决方案在产品功能上、产品化和易用性上仍然有巨大的改进空间，我们需要根据自己的 DevOps 需求和条件限制选择合适的方案并进行扩展和二次开发。

答疑环节

问：如何建设 devops 的平台都用到哪些技术？如何落地实施。

刘涛：好问题。建设 DevOps 平台，包括规范、工具、流程、文化。有多种不同类型方案，具体面向不同的场景和需求选择上也会有不同，不管采用哪种方案从概念模型上基本都包括版本控制、持续集成、制品库、自动化测试、环境管理、应用管理、部署规范几个部分。

具体到每个部分，可以根据目前公司的情况进行选择，涉及分散多种异构云环境或传统遗留物理机虚拟化环境的，建议采用以云管理平台为基础的方案。我之前写过一篇文章 << 打造 DevOps 持续交付高速公路 >>，介绍了一种以云管理平台为基础的 DevOps 平台解决方案，您可以参考一下。对于 DevOps 解决方案，想落地非常不易，其中的部署规范也非常重要，既要易于使用，又要灵活，对应用
业务系统最好不要有侵入性，不需要修改已有代码，才好落地。

问：基于 DevOps 的解决方案主要分几类? 优缺点是什么? 未来演进的方向是什么?

刘涛：从类型上可分为传统配置管理类型、云服务提供商、传统 PaaS、云管理平台、基于容器的、互联网公司开源。具体优缺点在文章中第四部分和第五部分有详细的分析和说明，请参考。

对于未来演进方向，个人认为将主要向云管理平台和容器的方向以及与 IT 管理融和。主要的原因是多数企业采纳混合云，需要能够易用的，能够广泛支持在各种云环境虚拟化环境中部署和管理资源应用，以及需要支持传统及当前应用的、未来 Cloud Natvie 应用、微服务架构应用，和遗留的已经存在的运行中持续开发中应用的方案。

问：云计算的 devops 有什么不同?

刘涛：云计算的 DevOps 与传统的 DevOps 从目标上总体是相同的，但是云计算环境下的 DevOps 一方面面临的基础设施环境更加多样，相比传统的物理机虚拟化环境，增加了私有云或公有云环境，另一方面对于云基础设施本身又是弹性可编程的，所以在实现从代码到服务的整个转化过程中，云计算的 DevOps 会更加的快速和自动化，能够实现涵盖基础设施在内的应用全栈自动化和全生命周期管理。

最典型的例子就是，能够做到一键自动创建虚拟机并自动部署应用，同时自动化能够涵盖在不同私有云公有云虚拟化环境，并在应用部署后实现监控告警，基于监控自动故障处理，基于监控或时间自动或手动进行伸缩扩容缩容。

感谢魏星对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。