作者:張磊

編輯:小智

DockerCon 上重點發布的“Moby”，在國內技術圈引起了不小的震動。廠商們普遍為 Docker 公司釋放 Moby 專案拍手稱讚，一線技術圈（GitHub，HN）卻掀起了一陣 “口誅筆伐” 的小波瀾。容器圈內一位多年的 Docker 專案貢獻者甚至直接感慨：“從此社群再無 Docker！”這件事，究竟該如何解讀與看待？

背景介紹

DockerCon 2017 在四月如期舉行。近兩年隨著 Docker 公司逐漸在自己的商業產品上不斷加碼，現在的 DockerCon 類似於一場 “客戶 + 產品 + 戰略” 的大型釋出會，也讓全世界的後端開發者們感受到了容器技術 “當家花旦” 的獨特魅力。

誰也沒料到的是，這次 DockerCon 上重點發布的 “Moby”，卻在國內這個以往不太跟國際接軌的圈子裡引起了不小的震動。有趣的是，在廠商們普遍為 Docker 公司釋放 Moby 專案拍手稱讚的同時，一線技術圈（GitHub，HN）裡卻掀起了一陣 “口誅筆伐” 的小波瀾。知乎該話題下的一篇高贊匿名回答 ( 倒不如說是吐槽）：

更是一時間取代了 DockerCon 本身成為了技術圈裡爭相討論熱點。如此矛盾的表現，為這個本來就不太明朗的商業事件更增添了難以理解的色彩。

到底發生了什麼？

“Docker，還是Moby？”

一向善於創造 fancy 的新名詞的 Docker 公司，這還是頭一次因為一個新名字陷入尷尬的局面。而這次“危機”的源頭，則是 Docker 公司在並未對外釋放明顯訊號的情況下，直接將 Github 上原隸屬於 Docker 組織的 Docker 專案，直接 transfer 到了一個新的、名叫 Moby 的組織下，並將其重新命名為 Moby 專案。這此並無徵兆的突然“改名”和“移交”，正是本次 DockerCon 2017 上宣佈的唯一一個大新聞。對此，容器圈內一位多年的 Docker 專案貢獻者直接感慨：“從此社群再無 Docker！”

說的一點沒錯。

究竟如何解讀？

實際上，知乎回答的總結部分已經一針見血了：

“Docker 公司直接把原 Docker 專案改名成了 Moby，是為了將之前數年裡構建出來的龐大的粉絲團體和 Google 搜尋內容（Google search footprint）全部轉移到 Docker 公司的商業產品上。”

在開源專案的運營是一個系統工程，但是整個過程中確有這麼三個入口是維護者需要苦心經營的重中之重：

1. Google 搜尋結果
2. Stackoverflow 上的問答內容
3. Google Group 的討論話題

一個開源專案要想成功，一個重要的手段是在目標受眾群體中贏得廣泛的使用者基礎，然後以此為基礎構建外圍生態。說的更現實一點，就是必須要有熱度和知名度。只有不斷被受眾群體提及並且關注的開源專案才有機會生存下去。這個現實也是開源圈子裡向來”只認第一，不認第二“的一個重要原因。

Docker 專案可以說是近幾年最成功的後端開源專案之一，更難能可貴的是，Docker 專案的成功並非像 Tensorflow、Kubernetes 這種含著金鑰匙出生的名門之秀，也非像 Etcd 這種定位於核心依賴並且容易被納入已有體系的獨立模組。Docker 專案本身是帶著顛覆性的，是要求你推倒重來的（這不同於 Etcd）。但它本身又沒有什麼黑科技成分，沒有太高的進入門檻（這又不同於 TF，k8s），它全部構建於現有的作業系統技術之上，卻幾乎單靠著 Idea 本身就取得了巨大的成功。這種專案，短時間內不可能再出現下一個了，因為它的出現，幾乎就意味著一個新產業的誕生。

我們一般能夠從 star 數估計出一個開源專案背後的生態，但是 Docker 專案背後的生態和群體規模，恐怕要比4萬個 star 所能代表的意義要大得多。

成千上萬的使用者，支撐起國內外無數家創業公司的龐大產業，數十億美元的風險資本，龐大的關聯產業群體，甚至說它重塑了雲端計算市場也不為過。 “Docker” 這個 Google footprint 背後的價值，委實難以估量。

對於 “Docker 到 Moby” 的轉變，業界可謂眾說紛紜，但最為困擾使用者和開發者的，無外乎兩個問題：

1. 如果是為了更好的模組化 Docker 專案（所謂的“樂高”式的架構），那麼為什麼不能保留 Docker 專案的名字，然後再拆分？
2. 如果是為了更好的區分 “project 和 product” ，那麼為什麼不能給 Docker 公司的商業產品取個更好聽的企業版名字（比如 Moby），而保留 Docker 作為一個獨立的開源專案？

最後的結果是令人遺憾的，甚至都沒在社群進行公開討論的餘地。

所以，無論 Solomon 如何辯解，無論是手繪架構圖還是連發 Hacknews，這一次 “Docker 到 Moby” 的轉變過程，其背後透露出來的用意無比清晰而堅定：

“從今往後，Docker 關鍵字的價值只屬於 Docker 公司。”

這種略顯霸道的做法，正是一線開發者層面矛盾被激發的源頭。

但這冰凍三尺，又非一日之寒。

早在 Docker 專案剛受到廣泛關注不久，就已經有很多意見指出 Docker 這個名字既是公司名字，又是開源專案的名字，而且很快又成了公司商業產品的名字，這本身就是很大的隱患。但 Docker 公司並沒有採取什麼措施，反而更加關注和遏制任何第三方試圖濫用 Docker 關鍵字的苗頭。

Docker 公司有意無意之間製造的這個模糊地帶，在 Docker 專案高速發展的兩年裡，將開源社群用心經營出來的龐大受眾和使用者群體，同公司未來商業產品的影響力和目標客戶通過 “Docker” 關鍵字成功的統一起來。然後，在 “Docker 到 Moby” 這個原本可以用來修正這個錯誤的時間點上，Docker 公司又毫無徵兆地、以迅雷不及掩耳之勢完成了 Docker 專案的重新命名。至此，“社群再無 Docker”，就成了這個無比成功的專案最後的感慨。這也是 Github 上和 HN 上的開發者感覺被冒犯的主要原因。

我們無法判斷這是不是 Solomon 一個人的決定（筆者傾向於這應該是董事會共同完成的戰略決斷，甚至有可能有傳說中 VC 方面的壓力），但這件事情本身的發展過程，卻同“善意的獨裁者”這一形象不謀而合。沒有投票，沒有徵詢，沒有公開的文件和章程來遵守，Docker 這個開源專案從誕生到“消失”，遵循著的都是不斷顛覆人們預設的決定。我們甚至很難被說服 Docker 是一個真正的開源專案。有時候，我們覺得它更像一個商業產品的特定階段，甚至，還帶有幾分傳奇色彩，故意讓我們看不清，摸不透：

“它崛起，它輝煌，它使命完成，它消逝不見”。

我們還有 Moby

困惑和焦慮，成為了 DockerCon 之後容器圈裡的普遍情緒，尤其我們國內的 Docker 圈子比國外熱度更高，產業也大，隨之而來的失望也更大。像往日熙熙攘攘的容器技術討論群裡，冷不丁有人問一句“Docker 改名了，我們怎麼辦？”，實在難有幾個靠譜的迴應。事實上，我們自己的開源專案裡也 vendor 了“github.com/docker/docker”。但是當討論到某個需要修改的 Docker 程式碼時，我們也很困惑：誰知道我們要改的部分將來會拆到哪裡去呢？是 Moby 下面，還是 Docker 下面？沒人知道。

不過，至少有一點是可以肯定的，現在的 Moby 專案，依然會扮演著 Docker 容器圈裡的重要角色。拆分之後，Moby 專案的獨立性和健壯性也能有更好的保證，社群裡的開發者和維護者還可以專注於自己熟悉的模組，而不是像現在一樣擁擠在一個 Docker 專案上不可開交。

更為重要的是，廠商和一線開發者，對 “Docker 到 Moby 的轉換” 可以說是完全不同的感受。對於 Google，CoreOS，RedHat，Mesos 等玩家來說，一個拆分後的、不隸屬於 Docker 公司的開源專案，明顯增加了更多合作而非競爭的機會。就拿 Google 來說，作為以往很容易被當靶子的一方，動不動就 “碾壓 Kubernetes” 的拙劣對比估計很難再現了，一個真正開放的社群，在公開場合對同類項目的寬容、友善和協作才是主流基調。

事實上，Moby 開源專案今後的路線，在工業界已有範例，比如 Cloud Foundry 專案。Pivotal Cloud Foundry（PCF）作為一款 PaaS 商業產品，在全球範圍內已經取得了巨大的成功，世界 500 強三分之二已經成為了 P 家的優質客戶。但如果好奇的話，你會發現 GitHub 上並沒有一個叫 CloudFoundry 的專案，而是以多個功能模組的方式散佈在 cloudfoundry 組織下面，比如 UAA，GoRouter 等等。然後，開源社群使用者可以通過一個叫 cf-release 的專案編譯出來一套完整的社群版 CloudFoundry 供自己部署和使用。

Docker 公司目前的處理方法也是類似的。Docker 公司旗下兩款產品分別是 Docker-CE（社群免費版）和 Docker-EE（企業收費版），它們都必須從 docker.com 官網下載下來使用（這是區分專案和產品的一個重要方式）。你並不會找到有一個開源專案叫 Docker-CE，但是你可以使用 Moby 組織下面的各個專案自己編譯一個跟 Docker-CE 功能一樣的軟體出來。不過，估計少有人會這麼做吧。大多數人應該還是圖個方便會下載使用 Docker-CE，這也可以說是 Docker 公司的一個小手段：你都用了 CE 了，試一下 EE 又何妨呢。

LinuxKit

在 Moby 體系中，還有一個專案也值得關注，那就是 LinuxKit。細心的人可能已經發現了，LinuxKit 的前生是 https://github.com/docker/moby 專案（Docker 公司這玩兒名字是有多溜）。實際上，你如果用過 Docker for Win 或者 for Mac 的話，就知道在這種非 Linux OS 場景下，Docker 其實是啟動了一個叫 MobyLinuxVM 的虛擬機器來跑 Docker 容器的，為了能夠讓這個額外的 VM 層足夠輕量級，核心裁剪和定製的工作就必不可少，這正是 LinuxKit 專案的來源。

比較有意思的是，DockerCon 上對 LinuxKit 的宣傳都是在“安全”兩個字上。這難免有抓眼球的嫌疑，定製宿主作業系統確實能夠降低宿主機的被攻擊面，但這並不改變容器本身在多租戶環境中隔離性和共享核心的問題本質。這種推廣方式也確實一度引起了國內一些使用者的誤解。不過，在使用了精簡 OS 之後，使用者在雲上啟動宿主機的時間就會大大減少，這的確是實實在在的好處。

那麼究竟應該怎麼解讀 LinuxKit 呢？

首先需要明確的是：LinuxKit 本身並不是一個精簡作業系統，它是用來編譯出可執行的精簡作業系統映象（包括 kernel，disk.img，BIOS.iso 等）的工具，這一點區別，國內有些介紹文章也不經意混淆了。

其次是它的使用方式：使用者首先需要使用 LinuxKit 工具來製作一個精簡作業系統，然後在 IaaS 上或者裸機上使用 KVM 等來使用這個系統啟動一個虛擬機器來把這個作業系統執行起來。

需要注意的是，在製作的過程中，使用者希望啟動的 Docker 映象也是要打包進去的。這樣虛擬機器啟動後就會使用事先打包進的 Docker 映象來啟動容器程序，這個過程由內建 containerd 和 runc 來完成。

所以，這個通過 LinuxKit 打包出來的 OS 映象確實具備了“可移植性”，但實際上還是要藉助虛擬機器來執行在 Mac 上或者 Windows 上等。這其實跟 CoreOS 等各種各樣的專門用來跑容器 OS distro 區別不大。

另外，通過 LinuxKit 生成的這個可執行 OS 映象，同時打包了作業系統和待執行的應用，這聽起來是不是有點熟悉？沒錯。LinuxKit 正是 Unikernels 團隊的作品，可以毫不隱晦的說，LinuxKit 實際上是一種 Unikernels 概念的更大眾化的實現。畢竟，相比起徒手製作 Unikernels 映象的過程，使用 LinuxKit 工具就要輕鬆多了。當然，這也意味著 LinuxKit 比 Unikernels 還是要重的，在實際測試中無論在資源使用上，還是啟動速度上兩者都有明顯差距。

總結成一句話：LinuxKit 所定義的是一種 Unikernels 風格的、專門為執行容器任務而定製的 OS distro。

既然還是 OS distro，那麼它的場景跟 CoreOS、RancherOS、RedHat Atomic 也是類似的。我也相信 Docker 使用者應該沒興趣在裸機上大規模使用 LinuxKit，雖然 “使用 KVM 啟動一個虛擬機器” 這項工作被 LinuxKit 接管了，但接下來 “徒手” 進行虛擬化管理的工作能勝任的人恐怕就不多了。

但是在 LinuxKit 正在發力的公有云領域，OS distro 確實很有發揮空間。在這裡，使用者並不需要關係下面的虛擬機器部分，就比如已經支援的 GCE 吧，使用者只需往 GCE 上傳自己的 build 出來的 LinuxKit OS 映象，就可以在雲上啟動一個虛擬機器來執行它，而打包進去的容器也隨之啟動了。這就實現了宿主機層面的一致性，也是在解決了 “這份程式碼在我機器上是可以跑” 的問題之後，“這個 Docker 映象在我的機器上是可以跑” 這個新生問題的也終於得到了緩解。

當然，既然是 OS distro，你也可以在這個 OS 映象中打包 Kubernetes binary，或者 swarmd，這樣就相當於直接拿這些機器當宿主機在 GCE 上來搭一個容器雲了。

不過話說回來，任何一種 OS distro 的目的之一，都是要製造 Vendor Lock，LinuxKit 也不例外。對於公有云提供商來說，這不是個友善的訊號。想象一下，將來某一天 AWS 上的容器使用者都不使用 AMI，而是使用 LinuxKit 映象來啟動虛擬機器來跑容器了，那就真尷尬了。所以，如果真說 “降維打擊”（事實上，我認為這個詞開始被濫用了，只有它的原創者 Frank Yu 的精彩演講裡形容 Docker 和 PaaS 的關係才是最形象的一次比喻），LinuxKit “打擊” 的是所有在作業系統層面試圖針對容器做文章（包括 distro，安全補丁，精簡核心等等）的玩家，這個覆蓋面可不小。各家公有云，RedHat，CoreOS，Rancher 等大小公司恐怕都在其中。從這個角度來看，LinuxKit 的推廣難度，可想而知。

最後提一句，LinuxKit 是自己一個單獨的 org，不屬於 Moby，也不屬於 Docker，不繫結 SwarmKit，不內建 Docker Engine，其雄心壯志確實略見一斑。正如一位 Kubernetes 專案貢獻者的評論所說的那樣：這傢伙不做 Unikernel 了，改做 Universal Kernel 了。

寫在最後

當我們靜下來重新審視 DockerCon 的這幾項內容，不難發現，大多數容器使用者實際上並無需過分糾結 Docker 或者 Moby。免費的 Docker-CE 會一直存在，Moby 開源社群依然會活躍，而且模組化後，要 hack 還變容易了，何樂而不為？

更何況，絕大多數使用者都應該是在使用諸如 Kubernetes，DC/OS，SwarmKit 等上層編排工具的，在 containerd 都已經歸屬 CNCF 的今天，下層 runtime 的風吹草動實在不應該浪費大家時間去做過多思考。我相信，無論是原 Docker 專案的開發者，還是是心有不甘的匿名使用者，最終還是希望能安安靜靜的寫程式碼，“Docker 還是 Moby” 的討論其實並沒有太大意義。

唯一值得我們銘記的是，無論是過去還是現在，開源社群都並非 “世外桃源” 般的淨土，它是現實商業市場在技術領域的延伸，它正在迅速地吞噬著現代軟體世界，改變著我們的競爭規則。這裡既有激烈的廠商鬥爭，也有友善的跨國協作，更有 Docker 公司這樣的模式創新者來不斷顛覆我們的思想。

作為身處其中的技術人員，唯有時刻保持對技術心存敬畏，對客觀事實冷靜思考，不盲從，不熱捧，方才能有更堅實的立足之地。就如我們一度難以抑制的 Docker 熱潮，此刻確實需要降溫。

作者介紹

張磊，Hyper 專案成員，Kubernetes 專案 Project Manager 和 Feature Maintainer，CNCF 成員。

文章來自微信公眾號：InfoQ