BT

您是否属于早期采用者或者创新人士?InfoQ正在努力为您设计更多新功能。了解更多

DevOps ≠ Chef/Puppet

| 作者 阮志敏 发布于 2014年2月17日. 估计阅读时间: 1 分钟 |

DevOps是一个热词,但是毫无疑问,也是未来的趋势(注1)。高效率的IT组织常常贴着DevOps的标签,是人们讨论的焦点和学习的对象。2009年时,人人都在讨论如何像Flickr一样一天内完成十几次的部署(注2)。今天,人人都谈论如何像Netflix/Pinterest一样基于云基础设施构建大规模、高可用、可伸缩的服务(注3)。

如何才能实现DevOps呢?很多人会不假思索地告诉你,使用Chef/Puppet,你就能实现DevOps。于是,DevOps变成了一个简单的问题,选择Chef还是Puppet。这并不奇怪,在开源软件盛行的今天,各种软件声称自己是DevOps工具,而人们通常不会去思考一项新技术或者新思路背后的缘由,人们需要的是“银弹”。

如同Agile,把DevOps等同于工具层面的Chef/Puppet,是错误的,会严重束缚人们的思维。在国内Cloud Native应用开发时代即将开启的今天,充分认识DevOps是很有必要的(注4)。

(一)DevOps不仅仅是工具

DevOps是Agile的延伸,Ailge依靠Dev & Biz部门紧密协作,通过增量交付的方式来解决需求多变的难题。DevOps则进一步延伸到IT运维,通过Dev & Ops的紧密协作提高软件交付的质量和频率。人的重要性大于流程,流程的重要性大于工具。这个结论适应于Agile, 也同样适用于DevOps。工具带来的影响是短期的和片面的,流程和人所产生的影响是长期的和全面的。

事实上,大部分人都知道这个道理,只是在潜意识中仍然把DevOps当成Chef/Puppet等工具。建设DevOps的正确步骤应该是充分理解DevOps的原则,认真分析自身需求和条件,选择正确的方法和流程,最后才是选择或构建适当的工具。Learn By Example仍然是学习和建设DevOps的重要途径。在今后的各种会议上,分享DevOps经验会越来越多。我们应该不仅仅关注讲演中提到的工具,更要多关注流程、组织结构和文化方面的分享。

DevOps不仅仅是工具,即便是工具,其也是建设DevOps所需工具链中的可选工具。

(二)Chef/Puppet只是DevOps工具链中的可选工具

DevOps目的是打造标准化的、可重复的、完全自动化的Delivery Pipeline, 其范围涵盖需求,设计,开发,构建,部署,测试和发布。除了需求、设计和开发外,其他的四个步骤都是可以自动化的。自动化是提高可测试性,一致性,稳定性和交付频率的核心。

下图来自IBM Agile, ITITL, Cloud How DevOps brings it all together 。该图非常清晰地解释DevOps如何实现交付的自动化(注5)。

图中DevOps流程所需要用到的工具和环境有:

  1. 源代码版本控制工具: 比如SVN, Git等。
  2. 持续集成工具:比如Jenkins, Bambo等。
  3. Artifact存储仓库:持续集成构建后的artifact都统一放在一个仓库中,比如Nexus/Artifactory, 当然也可以是FTP, S3等。
  4. 配置和部署工具:Chef/Puppet/CFEngine, Fabric/ControlTier,也包括新兴的Docker等。
  5. 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来实现后续的部署和配置。
  6. 测试工具:除了传统的测试工具外,还需要模拟Infra灾难、验证系统健壮性的工具,如Netflix的Chao Monkey。
  7. 发布工具:一般情况下,人们需要拥有DTAP四个环境,即开发环境、测试环境、Staging环境和生产环境。每种环境的作用,部署方式和代码版本等是不一样。比如开发环境是持续部署的,测试环境是定期如每天晚上自动部署,Staging和生产环境是手动触发的。
  8. 云基础设施:包括AWS/Azure等公有云,Cloudstack/Openstack等私有云。

因此,我们看到,Chef/Puppet只是实现DevOps工具链的可选工具,可以用来实现配置和部署自动化。但是仅靠Chef/Puppet本身无法实现Full-Stack部署自动化。

(三)仅靠Chef/Puppet本身无法实现Full-Stack部署自动化

如果要实现Full-stack Automation,那么就必须实现环境创建自动化,软件安装和配置自动化,应用部署和配置自动化,监控和告警自动化,故障检测和恢复自动化,扩展自动化,如下图所示(注6)。

  1. 环境创建:创建VMs、网络、存储、负载均衡,协调不同角色VMs的创建过程和配置。
  2. 软件安装和配置:操作系统配置,比如创建用户、组,设置ulimit参数等;基础软件安装和配置,比如mysql/nginx。这些软件的特点是变动不频繁。对于Chef/Puppet来说,这个步骤的自动化是其最擅长的。它们都提供大量现成的Recipes,并抽象各种异构系统之间的差异。
  3. 应用部署和配置:部署应用代码,比如war包、db脚本、php/rails代码等。这部分的变动是频繁的。对于Chef/Puppet来说,其是可以做这个工作的,但是很多人认为用Fabric/Glu等更为合适。另外,对于复杂的系统来说,如果保证升级期间系统的可用性,系统的各个应用组件需尽量是无状态和松耦合的。如果系统的组件之间是有依赖的,那么升级期间必须动态地协调(Orchestration)、控制好相关组件的行为。
  4. 监控和告警:包括OS级别和应用级别的可用性和性能监控。如果发现异常,需要能够自动发出告警信息。
  5. 健康检测和恢复:为了应付云基础设施故障,系统需要Design By Failure. 在异常发生时,系统可以发现并进行自动处理。
  6. 自动伸缩:一般情况下,业务存在高峰期和低估期。为了节省成本,系统应该是可以自动伸缩的。

对于上述的每一个步骤,看似都存在现成的工具可以用来实现自动化。但是,实现Full-Stack部署自动化从来就不是一件容易的事情,绝非简单通过选择、拼凑相关工具即可实现。Autodesk中国研发中心最近在InfoQ上分享了他们基于AWS的自动化部署实践。文章详细阐述了业务目标,设计目标和限制,和最终的实现方案,是一个非常好的案例。在这里,我们再来分析一下两种差异较大的实现方式。

(1) 基于PaaS的实现方式 (以Cloud Foundry为例)。

环境创建

用户不需要创建物理资源环境,Cloud Foundry会自动创建并分配资源给各个租户,用户无法控制底层OS等

软件安装和配置

用户不需要软件安装。Cloud Foundry已经安装好相关软件,只是支持的类型和版本有限

应用部署和配置

Cloud Foundry提供接口,用户调用接口进行应用部署和配置。应用类型必须是Cloud Foundry支持的,只能进行有限的配置,比如Tomcat的配置参数等

监控和告警

Cloud Foundry提供监控服务,但是Metric类型有限,无法支持自定义Metric

健康检测和恢复

Cloud Foundry提供Container级别的健康检测和恢复

自动伸缩

基于Cloud Foundry 提供的monitoring 接口和应用控制接口,可以实现instance级别的自动伸缩

貌似这种方式是最完美的方案,Cloud Foundry基本替你实现了上述的所有自动化步骤,应用开发人员只需专注于应用逻辑本身的开发。然而,Cloud Foundry也限制了用户的选择权和控制权,特别是大型的、复杂的、分布式系统,开发人员需要的是Full-Stack可控制性。

(2) Netflix的实现方式。

环境创建

通过自己研发的Asgard管理和部署工具实现

软件安装和配置

基础软件和配置都打包成AMI,基于Netflix自己的打包工具Aminator

应用部署和配置

同上,应用代码和配置也打包进AMI(注7)

监控和告警

Leverage AWS Cloudwatch, 同时也将通过自己开发的Servo

Lib将custom metric 发送至Cloudwatch.

健康检测和恢复

Leverage Atoscaling group,健壮性测试有Netflix自己开发的Chaos Monkey工具

自动伸缩

Leverage AWS AutoScaling Group

Netflix除了Leverage AWS的CloudWatch/Auto Scaling Group/ELB等服务外,自己也开发了一序列工具完成了Full-Stack部署自动化。这些工具通过Asgard这个可视化云管理和部署控制台集成起来。另外,Deployable image 这种部署模式虽可简化部署并确保一致性,但是一部分复杂性转移到了应用层面(注7)。系统的各个组件是无状态和松耦合,同时还需要Eureka这种服务来实现中间层的负载和failover。

在上述两个案例中,我们都看不到Chef/Puppet的影子。即便是Cloud Foundry自身的部署工具Bosh,但也不是基于Chef/Puppet。 所以,尽管Chef/Puppet非常流行,并且有很多成功案例,但是我们决不能把DevOps = Chef/Puppet。它们只是建设DevOps所需工具链中的可选工具,仅此而已。

参考文档

注1: What’s DevOps?

注2: 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr

注3: Ops, DevOps and PaaS (NoOps) at Netflix

注4: 对国内云计算三个现象的思考

注5: Agile, ITITL, Cloud How DevOps brings it all together

注6: “It’s the App, Stupid!” on Orchestration, DevOps Automation and What’s in Between

注7: Netflix deployable image

关于作者

阮志敏,AWS认证架构师,目前在三星中国研究院从事PaaS相关工作。


感谢丁雪丰对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

云计算给DevOps带来的新变化 by 阮 志敏

文章有点标题党的感觉。希望大家关注,1. 云计算带来的新变化。如何在可编程云基础设施上实现full stack的自动化,如何持续交付复杂的cloud-native应用。2.开拓思路,别沉迷于chef和puppet等特定工具。

另外,推荐把所有参考文档都读一遍。

拼写错误 by 陈 自欣

Chao Monkey 拼错了,应该是 Chaos Monkey

Re: 云计算给DevOps带来的新变化 by 乔 梁

文章真的标题党~~~~

DevOps ≠ Chef/Puppet by Wong Peter

它们只是建设DevOps所需工具链中的可选工具,仅此而已。

Paas平台虽然能提供一个基本的环境,让你只需专注于业务逻辑的开发,却也限制了你的控制权和选择权。如Netflix那样在Iaas平台上开发一些自己的full-stack工具才是王道。

devops~ by Zhao Xingtao

puppet只是其中的一环 仅此而已

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

5 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT