BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

定义DevOps 2.0:统一工具 + 环境整合?

| 作者 杨赛 关注 3 他的粉丝 发布于 2013年12月4日. 估计阅读时间: 6 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

UnitedStack的运维工程师Jim Jiang(@蒋闻天)同学在自己11月底的一篇博客文章《DevOps 2.0》中提出了自己对DevOps理念及相关工具演变的一个解读。他在从宏观角度分析了Foreman、Puppet、Juju、Razor、Crowbar、Chef和TripleO整个体系的关系和异同之后提出了一个观点:

我将TripleO之前的DevOps称为DevOps的1.0时代,而TripleO之后的DevOps称为DevOps 2.0 新时代。2.0 时代的一个显著特点是任何DevOps行为都有API,通过在外部编写程序我们可以主导DevOps的整个过程。

在Jim Jiang同学看来,DevOps世界的本质其实是五大块:Provison,Software Install,Configuration,State Management,以及Orchestration。

五大块的定义分别是:

  1. 自动把系统和软件安装好,不管是物理机还是虚拟机。(Provison)
  2. 对机器上安装的程序进行配置并且进行统一管理和收敛。(Configration)
  3. 掌控集群的状态,不管是资源状态还是安装状态,只要是状态我们都需要知道。(State)
  4. 在集群上方便的安装软件 (Software)
  5. 编写一个剧本将资源的调度和软件的配置协调起来。(Orchestration)

Jim Jiang同学对现有的各个运维自动化工具列了一个表格:

image

上图中除了最底层以外的其他工具都无法覆盖所有的五大块,因此Jim同学说:

传统的DevOps不是缺胳膊就是少腿,整合起来很尴尬。

最重要的是,在传统的DevOps工具下,

整个架构被一刀切为了两部分,管理物理设备的部分和管理虚拟化两个部分。

… …这个方案看起来很不错,但是要运行起来关键是要一个粘合程序,能协调全部的工作,否则离不开人工干预。

……粘合程序为了迎合其他组件而做出一些不得已的妥协,和臭名昭著的中间件是一个道理,会变得越来越臃肿,越来越和初衷不同,等到实在忍受不了这种事情了以后必然要重构。

那么Jim Jiang同学提倡的TripleO又是怎么一回事呢?这在他的另一篇文章《TripleO, Openstack Deploy On Baremetal Openstack》进行了更加详细的描述:

TripleO的目标是简化OpenStack部署,它开发了一个自运维的OpenStack基础设施,它由裸机安装部分(nova baremetal or ironic)、软件安装部分(diskimage-builder)、Orchestration工具(Heat)、镜像内DevOps工具(Puppet Or Chef)组成。

TripleO这个名称的来源是“OpenStack deployed on and with OpenStack”这个词组,意思是“用OpenStack部署,部署在OpenStack之上的OpenStack”。

这样做的好处是什么呢?Jim Jiang同学总结了两点:

  1. 只用一个工具就能把一个集群管理起来,不用依赖于一大堆第三方工具的堆砌
  2. 用Ironic组件屏蔽了物理层的实现,抽象出相同的接口给Nova调用,对上层透明

Jim Jiang不是第一位提及DevOps 2.0概念的同学。在2012年6月,GigaOM上发布了一篇名为《Star Trek’s Dr. McCoy and DevOps 2.0》的文章,最早提出了DevOps 2.0的概念。该文作者Dave Roberts是ServiceMesh公司的CMO、战略SVP和布道师。

Dave在文章中对DevOps提出了如下定义:

DevOps有点像是《星际旅行》里面的那个传送装置。DevOps的目标是创建一系列流程+工具的组合,这套组合可以将一个现代企业应用在它的开发环境中解耦,再在宇宙另一端的生产环境上重现。传送后的应用必须能够保持正常运行的状态——有求必应。

Dave描述的“传统DevOps”跟“现代DevOps”最大的区别在于,传统DevOps对底层物理设备的管理无能为力,而DevOps 2.0则可以将防火墙、负载均衡一并纳入。这点和Jim Jiang同学的观点一致。

纳入物理设备也可以用另一种方式理解,那就是“带着环境一起走”:

环境本身也成为了软件设计中的一部分,并跟随应用逻辑一起,从生命周期的一个阶段转入下一个阶段。

无独有偶,在今年QCon上海《来自一线的敏捷实战》专题上,爱立信软件开发高级专家蔡煜(@larrycaiyu)分享了一个建设建立了ETA (Environment Tools Automation)团队的经验。蔡煜认为从团队的角度来看,一个团队如果光做工具,或者光做版本控制,光做持续集成,光做自动化这些,那么是很容易被孤立的,发展的空间很小,也没有成就感。而ETA这三部分工作如果有机会合在一块,事情的发展就会顺利的多。虽然跟DevOps这个话题没有直接的关系,但表明在其他领域也有人关注环境与软件整合的问题。

你对于DevOps 2.0的概念怎么看?或者换句话说,你对于物理环境和虚拟环境统一管理、环境本身与软件设计的整合这样一个方向有什么看法?欢迎交流!

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

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

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

臭名昭著的中间件:) by 曹 云飞

中间件有那么不招人待见么?搞Java的真离不开中间件

DevOps by 严 明明

自从运维的角度来理解DevOps是不是太片面了?

DevOps by 严 明明

自从运维的角度来理解DevOps是不是太片面了?

DevOps by 严 明明

自从运维的角度来理解DevOps是不是太片面了?

允许的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通知我

4 讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT