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

  • 杨赛

2013 年 12 月 3 日

话题:DevOps

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

DevOps