2015 容器技术峰会学习笔记(一)

jopen 8年前


【编者的话】2015 容器技术峰会刚过去不久,容器技术是一个怎样的发展历程? 大会上众多业界大牛又讲述了哪些跟容器相关的有趣的工具和案例呢? 本文作者作为与会听众,分享了自己的一些现场笔记和学习心得。

2015 容器技术峰会学习笔记(一)

就在昨天,我参加了在旧金山皇宫大酒店举办的总共700多人出席的2015容器技术峰会。的确,容器技术本身还很稚嫩,但是我想强调的一点是在此之前,它的前身(译者注: LXC等技术)实际上已经有很长一段时间的发展历史了。

这次峰会最有意思的一个部分莫过于听到各种各样的辛酸抗争史了。他们讲述了如何运用容器来克服现实世界中遇到的种种困难。这里面有很多也是我们在过去以及将来都实实在在能看到的,即容器技术为这个世界所带来的改变。

这次真的学到不少!以下便是我想要分享的我个人从这次容器技术峰会学习和记录的笔记的第一部分。

走向原生容器

Bryan Cantrill, Joyent

乍一听到Joyent这个名词,一般来说,人们更多的是想到它与Node.js之间的合作关系。而这一次,Joyent公司的CTO,Bryan Cantrill 来到这个平台,讲述了Joyent另外的一面:它所推出的SmartOS,Triton 及其在容器和虚拟化背后的一些技术发展史。

Bryan演讲的核心内容在于阐述容器本身由来已久的历史渊源。 它最早可以追溯到第7版Unix引入的chroot特性。你可以认为chroot算是容器世界里的 始祖 。它并不能很清晰的被界定为容器或者说它甚至就不是一个完整的容器,但是从chroot之中我们看到了容器世界未来的启示录。

Bryan 随之讲述了FreeBSD的Jails,以及Sun微系统尝试过的Zones。他们被公认为是第一次“真正”意义上进军到容器领域的相关技术。

如果想进一步了解这些内容,Bryan 建议可以看下“Solaris(2002)的虚拟化和命名空间隔离性”这篇论文。

文章概述了五项主要原则:安全性 > 隔离性 > 虚拟化 > 细粒度 (少量资源的分配) > 透明度(API在Zone内部对操作系统的操作和调用需要尽可能的和外面保持一致)。

接着,Bryan 把注意力转向了硬件虚拟化。换句话说,也即是虚拟机。不出所料,他们也有一段有趣的发展历史。Bryan 登陆了wayback machine,并且访问了由IBM开发的 system 360 或者说 S/360。它算的上是一个历史性的突破和改变,至此之后计算机才有了完整的CPU指令集。

当时,它的竞争对手(Honeywell)开发了一台机器名为“解放者”。而Honeywell的机器在旧指令集的抽象虚拟化方面比360做的更加出色。这大概是硬件虚拟化战争里打响的第一枪吧。

快速切到Vmware在x86架构基础上探索硬件虚拟化的历程。我们至今仍然能够看到它很多相同的弊端,就跟我们回头去看“解放者”(我喜欢这个 名字)一样。Cantrill 指出,虚拟机过低的资源利用率会是一个致命伤。它将是虚拟机本身自带的特质,也往往会是其致命的缺陷。

Bryan 时常反思这一点。把大量的容器傻傻的运行在虚拟机(一个既有的非常丑陋 + 笨拙的解决方案)之上的做法也许会显得十分呆板和怪异。

Docker 应该算是容器领域里最常被提及的名字。然而,它从何而来? 在Docker之前又是谁? Cantrill 先生娓娓道来。原来,Docker诞生于 DotCloud 公司,最早是他们一个内部的PaaS项目。他接着问了一些很尖锐的问题。容器不是一个新概念。为什么它会突然变得引人注目?Docker最大的不同之处在 于它把重点放在使得应用变得更易于开发,而不单单只是为了简化部署。虽然,易于部署无疑是应用Docker的一个很好的附带效果。

Bryan 随后做出一个大胆的预测,“Docker将会取代apt,就像apt之前取代tar那样。”,相比于传统的应用依赖而言,Docker处理依赖的做法明显更为优雅。

演讲过程中他还插入了两张名人的画像。一位是 George Stephenson ,另外一位则是 Keith Tantlinger 。George Stephenson 定义了各种铁轨的标准宽度。Keith Tantlinger则发明了堆叠和加固运输集装箱的扭锁。这两个发明大大提高了贸易和运输效率。

Docker也正在做着非常相似的事情。容器的创建和管理因此被极大的简化。那么,我们不禁再次问道,为什么选择Docker? 原因即在于它实际上可以算是容器技术在标准化和易用性两方面的一个完美结合。

Bryan认为这种标准和易用性将会催生出更多的容器类项目。随着这样的一扇扇大门被打开,最终也许会形成一个百花齐放的局面。

“我们将可以看到很多的转变,事实上我们现在已经见证了一部分。“

在此基础上,Bryan简单的展示了一下他和他在Joyent的同僚一直以来努力耕耘的一些成果。Triton是Docker宿主机虚拟化的一种 手段。用他的话来说就是,”Triton 让你可以通过一个集成了轻量的软件定义网络支持的弹性Docker宿主机集群来直接在裸机上安全的运行Linux容器。“ 真正的去虚拟机化!

如果你对Triton有点兴趣的话,可以直接 去到 Joyent的官方网站去浏览参观一下。

Bryan 最终用一个他自己的观点结束了整场的演讲:容器革命将会改变我们看待计算的方式。

容器,投产就绪

David Lester, 推ter

来自推特的David Lester紧接着来到了舞台中央。他的演讲内容重点放在阐述推特是怎样从一个巨大的Ruby On Rails的代码库迁移到像Mesos和Aurora这样的技术栈。可能对大多数人来说这也许还是一个很新的技术,但是它已经在推特内部实际经受住了4年 多的线上实战考验。

对于新手来说,Mesos 是什么? Mesos 最早是美国伯克利研究室的一个内部项目。它的目标在于提升资源的利用率并且容许软件能以一种更细致的,弹性灵活的方式共享资源。

换句话说,在传统的IT架构里,我们分配资源的计量单位是服务器。Mesos则允许更精细化的资源的切片和分割。底层的资源像CPU,内存等都被完全抽象化。像异构资源调度这样的经典问题立刻消失无踪。

回过头来,我们知道,任何基础架构层面的切换成本都是十分高昂的。那么是什么原因促使推特打算迁离Rails的呢?

业务尖峰

在天空之城播出的期间,一个特定的词出现在其日文版里。日本的观众们不约而同的发推谈论它,他们由此创造了一个推特上 每秒发推数 最高的历史纪录。Lester随即发问道,你的基础架构能够承受多大的业务高峰流量? 现场人群中大部分人的反应更多的是不自然的挪了挪座位。

Lester指出,天空之城的这个故事是一个很好的不可预见的突发业务尖峰的案例。

在2010年,推特也见证了一个可以预见的业务尖峰。 FIFA世界杯 期间看到了许多的”失败鲸“(推特错误页面的专用术语)。一旦进球,人们便会发出大量的推文,也因此会造成服务器的过载和当机。

在这个时期,推特开始下定决心要做出一些改变。

解决方案

方案一: 在发生问题时投入更多的机器。( 在”天空之城“这样的突发场景下不奏效)

方案二: 改善系统的可扩展性。

Dave 指出这里面也有一些核心条件必须满足。推特由数百位工程师组成。他们需要的是一个妥善的解决方案,这个方案可以实现一个可扩展的智能基础架构,但是同时也必须容许所有的工程师能够依托其上继续工作。

在这个领域里,将故障和开发的功能解耦会是一个很大的收益。额外地,微服务架构的设计也允许小团队拥有技术栈中特定组件的完全主权。

推特的技术栈由Mesos,Aurora,Finagle组成

Dave说这促成了他们的最终设计方案。Mesos作为”数据中心的神经中枢“,它监测和调度资源,但是不会作出任何的决策。实际上,Mesos是在服务器节点和应用之间的一个很好的抽象层。

关于资源调度的决策者,Dave告诉我们,他们最终选择了 Aurora 。它是一个调度器,你可以把它理解为是一个神经系统中大脑的角色。

最后,Dave介绍到 Finagle 是一个能够帮助不同组件之间良好通信的解决方案。

尽管可爱的Lester先生展示了很多相关的优秀项目,他也同样分享了一句忠告,”今天你听到的所有项目,都会想着去统治世界。没有人会愿意去做一个二等公民。“

换句话说,这些平台没有任何一个是中性的。讲师们也不会分享其他的平台。所有的嘉宾都偏向于告诉开发者们如何和他们所推崇的平台去交互,Mesos,Kubernetes,Openstack,Docker等等。

Dave认为这些生态系统未来将会需要做出一些妥协并且最终能够共同成长。具体到推特过去乃至将来对工具集的探索和建立而言,他们关注一些具象的指标。

首先,对于软件而言,和哪一个抽象层集成最合适?

其次,对于开发者而言,什么才是最棒的接口模式?

面向未来的资源抽象和接口

推特目前的技术架构是一个调度-资源-分配的模型。Dave不认为这便是基础架构的终极答案。他也不相信这个架构可以适配所有的业务场景。Mesos 抽象了整个数据中心。它使得整个数据中心看起来更像是一台巨型计算机。这是多么的美好啊!

然而,我们也可以去看看其他的项目,像Kubernetes,Docker等等。这些也都是异常强大 + 高度可扩展的工具,他们也许会引领下一个时代的潮流。这不禁使得Dave提出了一些开放性的问题:

  • 关于这些代表未来趋势的工具该如何克服遭遇的种种困难和障碍。
  • 在未来,统一的接口会是什么形式?
  • 命令行? 还是图形界面? 每个领域对应最合适的是什么?
  • 他们在本地和在云环境下会是一样的吗? 许多的本地的工具在云环境下都不是那么受追捧,反之亦然。
  • 也许像Docker这样的容器技术通过不断的迭代,而最终将会承担更多类似Mesos的职责。Swarm? 这只是一个开始。

Dave在演讲的最后再次重申了自己的观点,”每个人都想着统治世界。“ 他还认为,我们定义这些接口和抽象模型的方式决定了我们实现目标的快慢,那会是一个共同的更加美好的未来。

第一部分完。

原文链接: 2015 container summit notes and learnings part 1 (翻译:吴佳兴)