DevOps ≠ Chef/Puppet · DevOps的概念与实践（2014年）

> 作者阮志敏发布于 2014年2月17日 DevOps是一个热词，但是毫无疑问，也是未来的趋势（注1）。高效率的IT组织常常贴着DevOps的标签，是人们讨论的焦点和学习的对象。2009年时，人人都在讨论如何像Flickr一样一天内完成十几次的部署（注2）。今天，人人都谈论如何像Netflix/Pinterest一样基于云基础设施构建大规模、高可用、可伸缩的服务（注3）。如何才能实现DevOps呢？很多人会不假思索地告诉你，使用Chef/Puppet，你就能实现DevOps。于是，DevOps变成了一个简单的问题，选择Chef还是Puppet。这并不奇怪，在开源软件盛行的今天，各种软件声称自己是DevOps工具，而人们通常不会去思考一项新技术或者新思路背后的缘由，人们需要的是“银弹”。如同Agile，把DevOps等同于工具层面的Chef/Puppet，是错误的，会严重束缚人们的思维。在国内CloudNative应用开发时代即将开启的今天，充分认识DevOps是很有必要的（注4）。 ## （一）DevOps不仅仅是工具 DevOps是Agile的延伸，Ailge依靠Dev& Biz部门紧密协作，通过增量交付的方式来解决需求多变的难题。DevOps则进一步延伸到IT运维，通过Dev& Ops的紧密协作提高软件交付的质量和频率。人的重要性大于流程，流程的重要性大于工具。这个结论适应于Agile,也同样适用于DevOps。工具带来的影响是短期的和片面的，流程和人所产生的影响是长期的和全面的。 ![](https://box.kancloud.cn/2015-07-17_55a872903e08b.png) 事实上，大部分人都知道这个道理，只是在潜意识中仍然把DevOps当成Chef/Puppet等工具。建设DevOps的正确步骤应该是充分理解DevOps的原则，认真分析自身需求和条件，选择正确的方法和流程，最后才是选择或构建适当的工具。LearnByExample仍然是学习和建设DevOps的重要途径。在今后的各种会议上，分享DevOps经验会越来越多。我们应该不仅仅关注讲演中提到的工具，更要多关注流程、组织结构和文化方面的分享。 DevOps不仅仅是工具，即便是工具，其也是建设DevOps所需工具链中的可选工具。 ## （二）Chef/Puppet只是DevOps工具链中的可选工具 DevOps目的是打造标准化的、可重复的、完全自动化的DeliveryPipeline,其范围涵盖需求，设计，开发，构建，部署，测试和发布。除了需求、设计和开发外，其他的四个步骤都是可以自动化的。自动化是提高可测试性，一致性，稳定性和交付频率的核心。下图来自IBM [Agile,ITITL, Cloud How DevOps brings it all together](http://www.slideshare.net/CloudOps/agile-itil-cloud-mit-devops-in-die-zukunft)。该图非常清晰地解释DevOps如何实现交付的自动化（注5）。 ![](https://box.kancloud.cn/2015-07-17_55a8729049812.png) 图中DevOps流程所需要用到的工具和环境有： 1. 源代码版本控制工具：比如SVN， Git等。 1. 持续集成工具：比如Jenkins, Bambo等。 1. Artifact存储仓库：持续集成构建后的artifact都统一放在一个仓库中，比如Nexus/Artifactory, 当然也可以是FTP, S3等。 1. 配置和部署工具：Chef/Puppet/CFEngine, Fabric/ControlTier，也包括新兴的Docker等。 1. Cloud Provision工具：在云环境下，由于任何IT Infra资源都以编程接口提供，意味着Full-Stack Automation (from “bare-metal to running business services”)成为了可能。Cloud provision工具可以自己通过API构建(如Netflix Asgard)，也可以直接使用IaaS服务商提供的扩展服务如AWS CloudFormation & Opsworks，也可以使用第三方工具如Ringscale/Scalr等。相当一部分Cloud Provision本身也集成了Chef/Puppet来实现后续的部署和配置。 1. 测试工具：除了传统的测试工具外，还需要模拟Infra灾难、验证系统健壮性的工具，如Netflix的Chao Monkey。 1. 发布工具：一般情况下，人们需要拥有DTAP四个环境，即开发环境、测试环境、Staging环境和生产环境。每种环境的作用，部署方式和代码版本等是不一样。比如开发环境是持续部署的，测试环境是定期如每天晚上自动部署，Staging和生产环境是手动触发的。 1. 云基础设施：包括AWS/Azure等公有云，Cloudstack/Openstack等私有云。因此，我们看到，Chef/Puppet只是实现DevOps工具链的可选工具，可以用来实现配置和部署自动化。但是仅靠Chef/Puppet本身无法实现Full-Stack部署自动化。 ## （三）仅靠Chef/Puppet本身无法实现Full-Stack部署自动化如果要实现Full-stackAutomation，那么就必须实现环境创建自动化，软件安装和配置自动化，应用部署和配置自动化，监控和告警自动化，故障检测和恢复自动化，扩展自动化，如下图所示（注6）。 ![](https://box.kancloud.cn/2015-07-17_55a872905be6b.png) 1. 环境创建：创建VMs、网络、存储、负载均衡，协调不同角色VMs的创建过程和配置。 1. 软件安装和配置：操作系统配置，比如创建用户、组，设置ulimit参数等；基础软件安装和配置，比如mysql/nginx。这些软件的特点是变动不频繁。对于Chef/Puppet来说，这个步骤的自动化是其最擅长的。它们都提供大量现成的Recipes，并抽象各种异构系统之间的差异。 1. 应用部署和配置：部署应用代码，比如war包、db脚本、php/rails代码等。这部分的变动是频繁的。对于Chef/Puppet来说，其是可以做这个工作的，但是很多人认为用Fabric/Glu等更为合适。另外，对于复杂的系统来说，如果保证升级期间系统的可用性，系统的各个应用组件需尽量是无状态和松耦合的。如果系统的组件之间是有依赖的，那么升级期间必须动态地协调(Orchestration)、控制好相关组件的行为。 1. 监控和告警：包括OS级别和应用级别的可用性和性能监控。如果发现异常，需要能够自动发出告警信息。 1. 健康检测和恢复：为了应付云基础设施故障，系统需要Design By Failure. 在异常发生时，系统可以发现并进行自动处理。 1. 自动伸缩：一般情况下，业务存在高峰期和低估期。为了节省成本，系统应该是可以自动伸缩的。对于上述的每一个步骤，看似都存在现成的工具可以用来实现自动化。但是，实现Full-Stack部署自动化从来就不是一件容易的事情，绝非简单通过选择、拼凑相关工具即可实现。Autodesk中国研发中心最近在InfoQ上分享了他们[基于AWS](http://www.infoq.com/cn/articles/automated-deployment-practice-based-on-aws)[的自动化部署实践](http://www.infoq.com/cn/articles/automated-deployment-practice-based-on-aws)。文章详细阐述了业务目标，设计目标和限制，和最终的实现方案，是一个非常好的案例。在这里，我们再来分析一下两种差异较大的实现方式。 ## (1)基于PaaS的实现方式(以CloudFoundry为例)。 <table cellpadding="0" border="1" cellspacing="0" class="calibre32"><tbody class="calibre33"><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 环境创建 </td> <td width="492" class="calibre35"> 用户不需要创建物理资源环境，Cloud Foundry会自动创建并分配资源给各个租户，用户无法控制底层OS等 </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 软件安装和配置 </td> <td width="492" class="calibre35"> 用户不需要软件安装。Cloud Foundry已经安装好相关软件，只是支持的类型和版本有限 </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 应用部署和配置 </td> <td width="492" class="calibre35"> Cloud Foundry提供接口，用户调用接口进行应用部署和配置。应用类型必须是Cloud Foundry支持的，只能进行有限的配置，比如Tomcat的配置参数等 </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 监控和告警 </td> <td width="492" class="calibre35"> Cloud Foundry提供监控服务，但是Metric类型有限，无法支持自定义Metric </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 健康检测和恢复 </td> <td width="492" class="calibre35"> Cloud Foundry提供Container级别的健康检测和恢复 </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 自动伸缩 </td> <td width="492" class="calibre35"> 基于Cloud Foundry 提供的monitoring 接口和应用控制接口，可以实现instance级别的自动伸缩 </td> </tr></tbody></table> 貌似这种方式是最完美的方案，CloudFoundry基本替你实现了上述的所有自动化步骤，应用开发人员只需专注于应用逻辑本身的开发。然而，CloudFoundry也限制了用户的选择权和控制权，特别是大型的、复杂的、分布式系统，开发人员需要的是Full-Stack可控制性。 ## (2)Netflix的实现方式。 <table cellpadding="0" border="1" cellspacing="0" class="calibre32"><tbody class="calibre33"><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 环境创建 </td> <td width="492" class="calibre35"> 通过自己研发的<a href="http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html">Asgard</a>管理和部署工具实现 </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 软件安装和配置 </td> <td width="492" class="calibre35"> 基础软件和配置都打包成AMI，基于Netflix自己的打包工具<a href="http://techblog.netflix.com/2013/03/ami-creation-with-aminator.html">Aminator</a> </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 应用部署和配置 </td> <td width="492" class="calibre35"> 同上，应用代码和配置也打包进AMI（注7） </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 监控和告警 </td> <td width="492" class="calibre35"> Leverage AWS Cloudwatch, 同时也将通过自己开发的<a href="http://techblog.netflix.com/2012/02/announcing-servo.html">Servo</a> Lib将custom metric 发送至Cloudwatch. </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 健康检测和恢复 </td> <td width="492" class="calibre35"> Leverage Atoscaling group，健壮性测试有Netflix自己开发的<a href="http://techblog.netflix.com/2012/07/chaos-monkey-released-into-wild.html">Chaos Monkey</a>工具 </td> </tr><tr valign="TOP" class="calibre34"><td width="132" class="calibre35"> 自动伸缩 </td> <td width="492" class="calibre35"> Leverage AWS AutoScaling Group </td> </tr></tbody></table> Netflix除了LeverageAWS的CloudWatch/AutoScalingGroup/ELB等服务外，自己也开发了一序列工具完成了Full-Stack部署自动化。这些工具通过[Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html)这个可视化云管理和部署控制台集成起来。另外，Deployableimage这种部署模式虽可简化部署并确保一致性，但是一部分复杂性转移到了应用层面（注7）。系统的各个组件是无状态和松耦合，同时还需要[Eureka](http://techblog.netflix.com/2012/09/eureka.html)这种服务来实现中间层的负载和failover。在上述两个案例中，我们都看不到Chef/Puppet的影子。即便是CloudFoundry自身的部署工具Bosh，但也不是基于Chef/Puppet。所以，尽管Chef/Puppet非常流行，并且有很多成功案例，但是我们决不能把DevOps= Chef/Puppet。它们只是建设DevOps所需工具链中的可选工具，仅此而已。 ## 参考文档注1: [What’sDevOps?](http://dev2ops.org/2010/02/what-is-devops/) 注2: [10+Deploys Per Day: Dev and Ops Cooperation at Flickr](http://velocityconf.com/velocity2009/public/schedule/detail/7641) 注3: [Ops,DevOps and PaaS (NoOps) at Netflix](http://perfcap.blogspot.it/2012/03/ops-devops-and-noops-at-netflix.html) 注4: [对国内云计算三个现象的思考](http://www.csdn.net/article/2013-08-27/2816726) 注5:[Agile, ITITL, Cloud How DevOps brings it all together](http://www.slideshare.net/CloudOps/agile-itil-cloud-mit-devops-in-die-zukunft) 注6: [“It’sthe App, Stupid!” on Orchestration, DevOps Automation andWhat’s in Between](http://www.slideshare.net/uri1803/openstack-israel-summit-2013-its-the-app-stupid?ref=http://cloudifysource.tumblr.com/post/51957539224/its-the-app-stupid-uri-cohens-presentation-from) 注7: [Netflixdeployable image](http://techblog.netflix.com/2011/08/building-with-legos.html) ## 关于作者阮志敏，AWS认证架构师，目前在三星中国研究院从事PaaS相关工作。感谢[丁雪丰](http://www.infoq.com/cn/author/丁雪丰)对本文的审校。查看原文：[DevOps≠ Chef/Puppet](http://www.infoq.com/cn/articles/devops-is-not-equal-chef-puppet)