容器是如何變成技術界寵兒，為什么 Docker 成為容器頭牌？

這篇訪談的對象是曾經擔任 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