容器是如何变成技术界宠儿，为什么 Docker 成为容器头牌？
jopen 9年前
这篇访谈的对象是曾经担任 Joyent CTO 的 Jason Hoffman 。他认为，操作系统异构是虚拟机发展的原因。随着 Linux 和 Windows 成为主流操作系统，以及 64 位系统时代的来临，容器取代虚拟机是很自然的事情。他还反思了为什么 Joyent 会错失发展机会，介绍了目前正在做的非聚合硬件，展望了基础设施和应用架构的未来。
Jason Hoffman 目前担任 Ericsson 公司云系统技术负责人。此前，他是 web 托管公司 TextDrive 的联合创始人之一。 TextDrive 后来发展成为云计算提供商 Joyent ，他曾经担任 CTO 。最近，我访问了 Jason Hoffman ，集中探讨（1）为什么容器成为 TextDrive 和 Joyent 的核心；（2）容器已经在主流开发者和工程师中流行开来，这对于现在的信息技术有什么意义。
容器历经十几年的发展
SCALE: 从何时起，你开始意识到容器非常适合构建基础设施或者多租户平台？JASON HOFFMAN: 我第一次使用容器时？ ... 从 2000 年开始的头几年， FreeBSD 4 系列中已经包含 FreeBSD Jails 了。 2003 年，我已经把 FreeBSD Jails 应用到生产环境。 2002 年开始折腾 Jails 的情景，迄今仍然历历在目。
...
那时， chroot ——至少作为一个基本概念——已经出现很久了。在 Unix 圈，一直都存在这样的想法：限制用户进程的行为， chroot 实现这一点的方式既有点神奇又有点怪异。随后， FreeBSD Jails 诞生了。如果你要使用 jails ，首先得阅读源代码来了解如何配置它，然后再执行各种操作，例如，用 dd 移动文件系统。那时就得这么做。
后来，我们开始提供 web 托管服务 TextDrive 。所有服务都运行在一个大的 FreeBSD Jail 中。再后来，我们提供基于 FreeBSD Jail 的虚拟私有服务器服务。
当 TextDrive 发展成为 Joyent 时，最开始采用的是 Solaris Zones 技术，对不对？
不，用的是 FreeBSD Jails 技术。
...
我最早接触的 Solaris 版本是 Nevada ，里面包含 DTrace ， ZFS 和 Zones ，以及全部的源代码。我一下子就被征服了。
必须考虑当时的背景。 2005 年，市场上供应 64 位芯片的厂商只有 AMD 一家， Intel 还没有出产 EMT 芯片。用户仍然使用 32 位 计算机系统，最多只能寻址 4GB 内存。没有理由在 32 位内存的内核之上运行另外一个内核。
当服务器拥有超过 4GB 的内存时，就可以应用操作系统级别的虚拟化技术，包括 FreeBSD Jails 和 Solaris Zones 。
当你打造 TextDrive （最后变成 Joyent ）时，采用容器技术的根本原因是「利用有限的资源提供尽可能多的托管服务」吗？
根本而言，如何让用户感觉自己使用的是专用服务器，同时提高整个物理服务器的实际利用率。
...
当时， Solaris 是最可靠的操作系统。我的天，它内置 ZFS 和 DTrace ，还支持 64 位。有了 ZFS ，你能够很方便地复制文件。利用 DTrace ，你能够查看系统的实际利用率，以及人们正在系统上做什么。你不用硬性分配内存，还可以超卖。一台物理服务器，你可以把它当作 1.5 台、 2 台、 3 台或者 4 台服务器卖出去，服务器的利用率相当高。
这就是当时的思路。
Joyent 的操作系统 SmartOS 的现状如何？它的基础仍然是 Solaris 吗？
SmartOS 仍然是开源的，仍然是 Joyent 的基石。就起源而言， SmartOS 是以 Illumos 内核为基础的发行版，而 Illumos 是开源 Solaris 的一个分支，因为 Oracle 收购 Sun 之后，决定不再开放 Solaris 的源代码。
为什么说 Linux 是首选的操作系统， docker 是首选的容器格式？
你坚定地相信 Solaris 是一个超级操作系统， Solaris Zones 是一种超级容器技术。为什么你仍然认为 Linux 是首选的操作系统， docker 是首选的容器格式？Linux 能够崛起，归功于它的软件包管理； docker 能够崛起，原因是它是一种新型的软件包管理。原因就这么简单。
FreeBSD 非常吸引人的一点是它提供了数量巨大的软件包和相应的软件包管理系统 ports 。实事求是地讲，让软件在 Solaris 系统中运行起来是一个痛苦的过程。Debian/Ubuntu 系统有 apt-get ， FreeBSD 有 ports ，但是 Solaris 从来没有提供类似的软件包管理系统。
时至今日，如果你要在一个操作系统上学习开发，你肯定选择一个能够方便地安装软件并且容易使用的系统：只要键入一个命令，就能安装好所需的软件，不必去了解如何编译这个软件。
...
人们选择一种 Linux 发行版而不选择另外一种发行版，原因是什么呢？主要是权衡下列因素的结果：目录是如何布局和命名的；默认使用的 shell 和安装的软件；软件包管理系统。
我认为， docker 是 Linux 打包系统的进一步演化... 人们已经习惯使用 AMI( Amazon Machine Image) 镜像，这是一种原子化、不可更改的镜像，只要抓取回来就能使用。 docker 为 Linux 带来了类似水准的打包功能。
Linux 和 docker 胜出的原因就是目录布局和命名的优美、程序安装方便、易于使用和打包，这些因素共同构成一个很棒的服务器系统。
但是从开发者的立场看，这不就是他们追求的吗？如果要构建一个面向服务的应用， docker 是如此易于使用，你肯定不想再花时间学习鲜有人知的 Solaris 配置。
千真万确，没错。
然而，我们还必须牢记：在运行一个大型服务时，如果碰到各种异常情况，你肯定希望能够有调试大型分布式系统的手段，例如， Solaris 提供的 DTrace 。这可不光是打包方便就行。我们处理目录布局和命名、软件打包等问题的手段是把问题最小化，即把它们封装在一起成为一个非常非常小的操作系统。
以前，使用 Solaris 时，键入
package in ，会新建一个 tar 文件，因为这个命令实质上是 tar 命令的封装。人们也许会反驳说不是这样的，但它确实是 tar 命令的封装。 Linux 系统有更好的软件包管理系统，用起来很方便。所有的软件及其依赖都在软件包系统中，只需一个命令就安装好了。我认为， docker 就是这种思路的新发展。
油Tube 视频： Docker 引擎简介
Amazon 是如何赢得云计算开发者的？
现在， Joyent 已经是一个成熟的云提供商。为什么其它云提供商没有走同样的容器和资源隔离的发展路线？我有个解释： AWS 太成功了，这些云提供商不得不跟随 AWS 的发展路线。2006 年，我们购买 Sun Grid 产品，上线了 网格容器服务。用户访问容器服务的 web 门户，上传 Excel 文件，对 Excel 文件包含的数据执行计算。我认为，这是个完全没有意义的产品，显得特别「网格做派」。
...
我们当时特别关注 web 应用 ... 所以，网格容器服务加载的是预先定义好的 web 软件和容器、数据库和容器，加上前置的弹性负载均衡组件。
当时提供的服务都是这种类型。我们甚至提供过 Ruby on Rails 应用服务，用户从 Subversion 等版本控制系统推送、部署和运行应用。愚蠢的是，我们没有继续做下去。有些对此不满的人，不再使用我们的服务，开始运作 Heroku 等平台和服务。
...
那时候，我们的客户包括 Wordpress.com 和 推ter 。我的意思是，位于旧金山的那些初创公司，现在都是 100 亿、 200 亿 …… 甚至 1,000 亿美金的估值，当时它们都是我们的客户。
随后， Amazon 发布了 S3 服务。 推ter 当时为什么要使用 S3 服务呢？因为开发者不知道如何在磁盘上建立一个散列化的目录结构，用来存储图像文件。他们只是建立一个超大的目录，里面保存了一百万张以上的图像。
第一个超级 推ter 用户是 John Edwards ，他有 5,000 个粉丝。我记得当时他正在竞选总统。那时候， 推ter 的图像还没有分页。每次加载一页推文，所有粉丝的头像都会重新加载。问题是这些图像文件保存在磁盘上， 也没有开启 HTTP 头部中的缓存选项。所以，“既然 Amazon 提供了 S3 服务，为什么不把所有的图像保存在 S3 中？ S3 就像是穷人的 CDN ”。
紧接着， Amazon 又推出了 EC2 服务。 EC2 实质上是一个批处理服务，处理的对象是保存在 S3 中的数据。 Amazon 采用一种非常棒的产品路线——渐进发展。那时候， Amazon 没有提供磁盘持久存储服务、没有 IP 地址服务，也没有负载均衡等服务。但是，用户使用 Amazon 已有的服务（即 S3 和 EC2），既方便又容易。
S3 是杀手级服务 ... 我们那时候只是让用户首先把日志和图像转储到 S3 中，然后再拉回到 Joyent 处理。随着 EC2 的出现，用户能够更好地处理日志，不需要再使用 Joyent 的服务了。
...
为了拓展业务， Joyent 做了很多决策。但是，我们本可以做出的最佳决策是留住那些 web 2.0 企业客户。
那时它们都是我们的客户。 Amazon 做得最棒的一项工作就是他们热爱那些客户。
这可能是 Joyent 所犯的最大的策略错误，不过，当时采用容器技术是没有问题的，很棒。
提高容器的运维和效率
现在出现了几种新的容器格式。如果人们开始以容器为基础构建应用，而不是把虚拟机作为度量或者计算的单位，这种做法更好吗？当然，绝对是这样。
我的团队刚刚发布了一种「非聚合硬件」，把服务器存储和网络的硬件部件拆散。这样，就可以做到一个板子上只有 CPU 和内存，另外一个板子只有网卡，还有一个板子只有硬盘。在板子的背面，内嵌硅光子，把电子信号转换成光，提供了非常高速的通信连接。你可以这么理解，你有 一个离 CPU 和内存几公里远的「本地硬盘」。
所有的组件都是单独管理和扩展的，所有的组件都是非聚合的，彼此之间通过硅光子建立通信连接。这是硬件领域的革命性创新。
在操作系统层面， Windows 和 Linux 都支持原生的容器。再经过两三年的发展，这些容器技术就会变得很出色。现在， VMWare 甚至宣布可以 在 ESX 上运行原生容器，原先这是一个在 ESX 上运行 ESX 容器的「秘密项目」。
...
我们与 Intel 合作开发非聚合硬件，接下来的两三年， Intel 也有可能与其它团队合作做类似的事情。非聚合硬件最终会完全具备技术可行性。原生的 Linux 容器会变得出色，原生的 Windows 容器会变得出色。硬件辅助虚拟化会变得不那么重要。只有当你需要把一个 CPU 细分使用时，才会借助硬件虚拟化技术，在一个内核上运行另外一个完整的内核。
有了非聚合硬件，就能够像堆积木那样，把服务器、存储和网络交换机组装成满足需要的硬件，然后应用原生容器，进一步细分硬件的使用。这将是未来的 主流。最近十几年，我们一直在生产环境中使用虚拟机管理器。它的作用会下降，测试开发是它的主要使用情景，此时需要把一个 CPU 细分使用。
在 Mesosphere 公司，我们一直这么类比：如果用户运行的系统要具备某种程度的扩展性，要用到某个编排系统，就必须采用类似 Google 公司采用的方式去运行系统。自动化、高效率地运行系统，这是终极目标吗？
是的。有了非聚合硬件，就不会存在浪费硬件组件的情况。不同的组件可以有不同的生命周期。采用渐进的方式报废和变更硬件组件，而不是一下子把整个系统替换掉。这才是刀片服务器的应有之义，而不是像现在这样，每隔几年就要全部换掉服务器。
如果你占用某个硬件设施的比例低于 50% ，这个硬件设施就是最主要的经济因素。事实上，过去你把 100 个机架聚合起来使用，现在你只要使用 20 个机架就能满足需要。这意味着，现在与过去相比，购买硬件设施的支出所占的比例更高。过去，系统的利用率不高，即使聚合起来，仍然是同样的低利用率。
硬件设施的占用率高，同时硬件之上的系统的利用率也很高，这样完美的系统，单靠非聚合硬件是实现不了的。容器加上非聚合机架式硬件，才能同时实现硬件设施的高占用率和系统的高利用率。
过去：虚拟机；未来： 128 位
现在回过头看，虚拟机时代是必须经历的吗？一直以来，主要问题是异构操作系统导致的不一致性。大概在 1998 或者 1999 年， VMWare Workstation 1.0 发布，到了 2003 年， Xen 诞生了。当时， 在 Linux 之上运行 Linux ，这个功能只有 Xen 有。所以说， Linux 从一开始就选错了。 Linux 应该选择容器模型，而不是 Xen 模型。当时的那些系统，都用软件实现了在一个内核之上运行另外一个内核。
...
有一帮人，像我们 Joyent 以及 Google 公司，从一开始就意识到操作系统异构是导致问题的症结所在。如果你决定采用同一个标准的操作系统，而不是一系列异构的操作系统，那么做虚拟化时你自然会采用操作系统级别的虚拟化技术，或者说容器技术。
为什么现实中既有虚拟机又有容器呢？原因有两个：第一，上世纪 70 、 80 和 90 年代的操作系统大战，存在多种主流操作系统；第二，系统从 32 位转换到 64 位，一下子支持大内存了，可以把多个操作系统聚合为一个系统。
人们首先用虚拟机解决操作系统异构的问题。随着这个问题的解决，以及 64 位系统支持大内存，容器的兴起也就自然而然了。细想起来，从 1999 年开始，凡是从头自主构建基础设施的厂商都选择使用容器。
先把对 docker 和 Linux 的疑虑放到一边，就基础设施和应用架构而言，我们正走在一条正确的道路之上吗？我能说现在是一个黄金时代吗？
有这么几件事。迄今， x86 是体系架构领域的赢家，除非需要 128 位芯片或者量子计算实用化了，否则它会一直赢下去。 x86 的胜出，消除了架构层的异构。在操作系统领域， Linux 和 Windows 胜出，消除了操作系统层的异构。
现在，你可以用更为原子化的视角看待基础设施：基础设施是由不可更改的模块像搭积木那样搭建而成，原子性和不可更改性成为基础设施的特性。
...
与此同时，我认为需要做的工作仍然有很多。我们还没有解决分布式计算中的大问题。怎样让分布式系统拥有某种程度的自治行为？如果可以做到这一点，运行在分布式系统之上的应用就能自行决定在哪里运行以及运行哪些功能。这就实现了应用程序的自主调度。
现在大多数人构建的分布式系统只是分布在几十个数据中心中。如果要构建一个分布式系统，能够调用分布在几百个、几千个、几万个甚至几十万个数据中心中的功能，我们还有很多工作要做。如何在此类基础设施之上构建自治的应用？
还要做很多工作。正如我已经说过的那样， 128 位芯片即将出现，一切又会变得一团糟。
原文链接：How containers became a tech darling, and why Docker became their poster child（翻译：柳泉波 校对：魏小红）
====================
译者介绍
柳泉波，读书踢球喝茶写程序。
来自：http://dockone.io/article/396