浅析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会更加的快速和自动化，能够实现涵盖基础设施在内的应用全栈自动化和全生命周期管理。
最典型的例子就是，能够做到一键自动创建虚拟机并自动部署应用，同时自动化能够涵盖在不同私有云公有云虚拟化环境，并在应用部署后实现监控告警，基于监控自动故障处理，基于监控或时间自动或手动进行伸缩扩容缩容。
感谢魏星对本文的策划和审校。
分享七款做好DevOps的强大工具
以前，开发（Development）和运维（Operations）总是相互指责。程序代码永远不会按照开发者的意愿及时更新，服务器的管理人员则对开发者随意简化进程搁置服务请求十分恼火。
直到DevOps的到来，一些工具消除了双方之间的隔阂，提供了从配置管理到应用程序移植的服务，这条战线便消失了。这里介绍几款最近颇受好评的DevOps工具。
1. Atlas
HashiCorp最新推出的Atlas提供了可视化的基础设施，在配置管理和服务搜寻之外，还提供了服务器、包容器和虚拟机。该项目是在其广受欢迎的开源项目Vagrant、Packer、Serf、Consul 和Terraform的基础上建立的，其特有闭源模式能使DevOps在AWS、谷歌计算引擎、Azure以及OpenStack等各种云服务中运行自如，此外，Atlas还提供了可用于开发、资源配置和维护应用程序的仪表板。
Lithium Technologies 工程师Justin Franks目前所用的开发工具是Vagrant，他正在考虑使用Atlas为公司的客户互动平台服务。Franks 说Atlas在Lithium Technologies已经投入使用，现在主要在测试其持续集成和配置的能力。“有很多的工具，比如Jenkins、Travis和Bamboo，它们都过不了最后资源配置的那一关。”弗兰克如是说。
Atlas自购系统的安装预计在今年年初进行。
2. Chef
Chef是一个系统和云端基础架构的框架，它可以通过被称为“recipes”的简短可重复脚本自行操作基础设施的建立、配置和管理。但Chef的实权其实只在于操作其可插拔的配置模块（又名“食谱”），而在Chef中有近2000个这样的模块。作为Chef的高调用户之一，Facebook最近开放了一些自己的Chef“食谱”的源代码，包括Taste Tester测试框架和Grocery Delivery，后者是用于监测源代码回购（如Git）并保持本地Chef服务器同步的工具。
宾夕法尼亚大学沃顿商学院也是Chef的用户之一。“Chef可自动化操作一些时间密集型和资源密集型的复杂任务，更重要的是它使我们能够集中精力进行创新和提高服务质量，”该校的技术总监Sanjay Modi在Chef网站的个案分析上说，“Chef也将为组织内的协作和工作效率提高带来更多的可能。” Chef已被使用于沃顿商学院的Amazon EC2资源、Linux节点和本地虚拟机的自动化配置管理。
3. Docker
Docker以其集装化技术为应用程序带来便携性，在Docker中，应用程序可以跨平台运行自给系统。Docker是由Docker引擎和Docker集线器组成的，前者是一个轻量级的运行时间和包装工具，后者则是应用程序共享和工作流程自动化的云服务。
“Docker已成为Yelp下一代测试和服务管理基础设施的重要组成部分，”Yelp 的技术总监Sam Eaton在Docker网站上的案例研究中说，“依赖性隔离和‘集装箱’的快速旋转使得开发周期和测试速度提高了不只4倍。”
4. Puppet
通过机器和软件的自动化配置和管理，Puppet公司从Puppet实验室提供数据中心的业务流程。最新发布的3.7版本推出了Puppet Apps，这是一款专用于应用IT自动化的应用，其包含的Node Manager，可用于管理大量常变系统。Puppet的开源版本也已推出。
斯坦福大学采用Puppet的开源版本来“解决开发新型数字图书馆服务和保持这些服务高性能安全运行之间的矛盾，”斯坦福大学的Bess Sadler在Puppet网站的视频推荐中如是说。
她还指出开发者应更多地参与系统管理，而系统管理员也同样参与了软件开发，于是，应用开发也就更加快捷省时。
5. SaltStack
SaltStack提供数据自动化、服务器配置、云端建设和应用程序配置的系统管理。事件驱动的云端基础架构自动化工具，可以自动运行DevOps工作流程中的任务。Deseret Digital Media已经采用SaltStack自动化运行环境长达两年，其特点是大约200个虚拟机用于运转生产和登台环境。
Deseret Digital的开发部主管Justin Carmony表示，SaltStack“使操作更加贴近开发者”。Deseret Digital有三个运营人员和30个开发者：SaltStack让研发与运营统一战线，比如在新服务器配置上。一般来说，运营和研发会一直争吵，无法达成统一意见。而SaltStack提供了一种通用的方法和通用语言来管理服务器，从而有助于双方消除误会，方便沟通。
6. ScriptRock GuardRail
GuardRail提供了配置监控，连续监测机器的配置状态。它可以确保用户的生产环境是符合质量保证以及测试和开发环境的。VersionOne，一个灵活项目管理平台的制造商，在遇到的配置漂移和自动化的挑战后，果断转向了GuardRail。
“开发者走捷径使自动化更易实现。为了在新的代理上运行已有创建，他们改变了之前用于其他创建的代码。于是基础设施的不稳定破坏了兼容多个生成代理的可能性。” VersionOne 的产品经理Ian Buchanan在案例分析中如是说。“而有了GuardRail，我们现在可以了解到任何生成代理是如何配置的，所以我们能够依照我们的意愿，确实地扩展到尽可能多的代理。”现在，VersionOne可以直观的看到配置漂移，可以记录预期，并创造了人类可读的测试，这相当于节省了一个专职的测试人员。
7. Splunk
Splunk是在整个应用程序的生命周期中实时寻找和修复问题的工具，它使开发者能够直接看到生产环境中的数据，而无需访问生产机器。Splunk协助用户进行DevOps过程，包括持续的集成和资源配置。
User EnerNOC使用Splunk大概五年了，这是一家为电网运营商等提供能量智能软件的公司。“Splunk从根本上改变我们操作生产系统的方式，”EnerNOC 公司的首席工程师James Nichol介绍说，“它使技术和非技术用户都能够深入了解一个非常复杂的系统，这个系统原本是他们无法了解的。我们已经有了虚拟服务器和开发经理，服务台运营商也建立了仪表板和警报，并开始深入挖掘数据——没有Splunk，这些都是不可能实现的。”