「從此社區再無 Docker？」那「Moby」 又是什麼？

作者｜張磊

編輯｜小智

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 公司的商業產品上。」

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

Google 搜索結果

Stackoverflow 上的問答內容

Google Group 的討論話題

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

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

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

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

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

如果是為了更好的模塊化 Docker 項目（所謂的「樂高」式的架構），那麼為什麼不能保留 Docker 項目的名字，然後再拆分？

如果是為了更好的區分 「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 成員。

今日薦文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！