BT

你的观点很重要! 快来参与InfoQ调研吧!

DevOps ≠ Chef/Puppet

| 作者 阮志敏 关注 0 他的粉丝 发布于 2014年2月17日. 估计阅读时间: 13 分钟 | ArchSummit社交架构图谱:Facebook、Snapchat、Tumblr等背后的核心技术

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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