小鯨魚大事記 | Docker誕生歷程之初出茅廬

做者：張磊

來源： 極客時間《深刻剖析Kubernetes》

 
你好，我是張磊。我今天分享的主題是：小鯨魚大事記之初出茅廬。

第一階段、初出茅廬

2013~2014年，以Cloud Foundry爲表明的PaaS項目，逐漸完成了教育用戶和開拓市場的艱鉅任務，也正是在這個將概念逐漸落地的過程當中，應用「打包」困難這個問題，成了整個後端技術圈子的一塊心病。

Docker項目的出現，則爲這個根本性的問題提供了一個近乎完美的解決方案。這正是Docker項目剛剛開源不久，就可以帶領一家本來默默無聞的PaaS創業公司脫穎而出，而後迅速佔領了全部雲計算領域頭條的技術緣由。

而在成爲了基礎設施領域近十年可貴一見的技術明星以後，dotCloud公司則在2013年末大膽更名爲Docker公司。不過，這個在當時就頗具爭議的更名舉動，也成爲了往後容器技術圈風雲變幻的一個關鍵伏筆。

若是我問你，現今最熱門的服務器端技術是什麼？想必你不假思索就能回答上來：固然是容器！但是，若是如今不是2018年而是2013年，你的回答還能這麼斬釘截鐵麼？

2013年，被人們寄予厚望的雲計算技術，從當初虛無縹緲的概念蛻變成了實實在在的虛擬機和帳單。而相比於的如日中天AWS和盛極一時的OpenStack，以Cloud Foundry爲表明的開源PaaS項目，卻成爲了當時雲計算技術中的一股清流。

這時，Cloud Foundry項目已經基本度過了最艱難的概念普及和用戶教育階段，吸引了包括百度、京東、華爲、IBM等一大批國內外技術廠商，開啓了以開源PaaS爲核心構建平臺層服務能力的變革。若是你有機會問問當時的雲計算從業者們，他們十有八九都會告訴你：PaaS的時代就要來了！

這個說法其實一點兒沒錯，若是不是後來一個叫Docker的開源項目忽然冒出來的話。

事實上，當時還名叫dotCloud的Docker公司，也是這股PaaS熱潮中的一份子。只不過相比於Heroku、Pivotal、Red Hat等PaaS弄潮兒們，dotCloud公司實在是太微不足道了，而它的主打產品因爲跟主流的Cloud Foundry社區脫節，長期以來也無人問津。眼看就要被如火如荼的PaaS風潮拋棄，dotCloud公司卻作出了這樣一個決定：開源本身的容器項目Docker。

顯然，這個決定在當時根本沒人在意。

「容器」這個概念歷來就不是什麼新鮮的東西，也不是Docker公司發明的。即便在當時最熱門的PaaS項目Cloud Foundry中，容器也只是其最底層、最沒人關注的那一部分。說到這裏，我正好以當時的事實標準Cloud Foundry爲例，來解說一下PaaS技術。

PaaS項目被你們接納的一個主要緣由，就是它提供了一種名叫「應用託管」的能力。在當時，虛擬機和雲計算已是比較廣泛的技術和服務了，那時主流用戶的廣泛用法，就是租一批AWS或者OpenStack的虛擬機，而後像之前管理物理服務器那樣，用腳本或者手工的方式在這些機器上部署應用。

固然，這個部署過程不免會碰到雲端虛擬機和本地環境不一致的問題，因此當時的雲計算服務，比的就是誰能更好地模擬本地服務器環境，能帶來更好的「上雲」體驗。而PaaS開源項目的出現，就是當時解決這個問題的一個最佳方案。

舉個例子，虛擬機建立好以後，運維人員只須要在這些機器上部署一個Cloud Foundry項目，而後開發者只要執行一條命令就能把本地的應用部署到雲上，這條命令就是：

$ cf push "個人應用"複製代碼

是否是很神奇？

事實上，像Cloud Foundry這樣的PaaS項目，最核心的組件就是一套應用的打包和分發機制。Cloud Foundry爲每種主流編程語言都定義了一種打包格式，而「cf push」的做用，基本上等同於用戶把應用的可執行文件和啓動腳本打進一個壓縮包內，上傳到雲上Cloud Foundry的存儲中。接着，Cloud Foundry會經過調度器選擇一個能夠運行這個應用的虛擬機，而後通知這個機器上的Agent把應用壓縮包下載下來啓動。

這時候關鍵來了，因爲須要在一個虛擬機上啓動不少個來自不一樣用戶的應用，Cloud Foundry會調用操做系統的Cgroups和Namespace機制爲每個應用單首創建一個稱做「沙盒」的隔離環境，而後在「沙盒」中啓動這些應用進程。這樣，就實現了把多個用戶的應用互不干涉地在虛擬機裏批量地、自動地運行起來的目的。

這，正是PaaS項目最核心的能力。而這些Cloud Foundry用來運行應用的隔離環境，或者說「沙盒」，就是所謂的「容器」。

而Docker項目，實際上跟Cloud Foundry的容器並無太大不一樣，因此在它發佈後不久，Cloud Foundry的首席產品經理James Bayer就在社區裏作了一次詳細對比，告訴用戶Docker實際上只是一個一樣使用Cgroups和Namespace實現的「沙盒」而已，沒有什麼特別的黑科技，也不須要特別關注。

然而，短短几個月，Docker項目就迅速崛起了。它的崛起速度如此之快，以致於Cloud Foundry以及全部的PaaS社區還沒來得及成爲它的競爭對手，就直接被宣告出局了。那時候，一位多年的PaaS從業者曾經如此感慨道：這簡直就是一場「降維打擊」啊。

難道這一次，連闖蕩多年的「老江湖」James Bayer也看走眼了麼？

並無。

事實上，Docker項目確實與Cloud Foundry的容器在大部分功能和實現原理上都是同樣的，可恰恰就是這剩下的一小部分不同的功能，成了Docker項目接下來「呼風喚雨」的不二法寶。

這個功能，就是Docker鏡像。

恐怕連Docker項目的做者Solomon Hykes本身當時都沒想到，這個小小的創新，在短短几年內就如此迅速地改變了整個雲計算領域的發展歷程。

我前面已經介紹過，PaaS之因此可以幫助用戶大規模部署應用到集羣裏，是由於它提供了一套應用打包的功能。可恰恰就是這個打包功能，卻成了PaaS往後不斷遭到用戶詬病的一個「軟肋」。

出現這個問題的根本緣由是，一旦用上了PaaS，用戶就必須爲每種語言、每種框架，甚至每一個版本的應用維護一個打好的包。這個打包過程，沒有任何章法可循，更麻煩的是，明明在本地運行得好好的應用，卻須要作不少修改和配置工做才能在PaaS裏運行起來。而這些修改和配置，並無什麼經驗能夠借鑑，基本上得靠不斷試錯，直到你摸清楚了本地應用和遠端PaaS匹配的「脾氣」纔可以搞定。

最後結局就是，「cf push」確實是能一鍵部署了，可是爲了實現這個一鍵部署，用戶爲每一個應用打包的工做可謂一波三折，費盡心機。

而Docker鏡像解決的，偏偏就是打包這個根本性的問題。所謂Docker鏡像，其實就是一個壓縮包。可是這個壓縮包裏的內容，比PaaS的應用可執行文件+啓停腳本的組合就要豐富多了。實際上，大多數Docker鏡像是直接由一個完整操做系統的全部文件和目錄構成的，因此這個壓縮包裏的內容跟你本地開發和測試環境用的操做系統是徹底同樣的。

這就有意思了：假設你的應用在本地運行時，能看見的環境是CentOS 7.2操做系統的全部文件和目錄，那麼只要用CentOS 7.2的ISO作一個壓縮包，再把你的應用可執行文件也壓縮進去，那麼不管在哪裏解壓這個壓縮包，均可以獲得與你本地測試時同樣的環境。固然，你的應用也在裏面！

這就是Docker鏡像最厲害的地方：只要有這個壓縮包在手，你就可使用某種技術建立一個「沙盒」，在「沙盒」中解壓這個壓縮包，而後就能夠運行你的程序了。

更重要的是，這個壓縮包包含了完整的操做系統文件和目錄，也就是包含了這個應用運行所須要的全部依賴，因此你能夠先用這個壓縮包在本地進行開發和測試，完成以後，再把這個壓縮包上傳到雲端運行。

在這個過程當中，你徹底不須要進行任何配置或者修改，由於這個壓縮包賦予了你一種極其寶貴的能力：本地環境和雲端環境的高度一致！

這，正是Docker鏡像的精髓。

那麼，有了Docker鏡像這個利器，PaaS裏最核心的打包系統一會兒就沒了用武之地，最讓用戶抓狂的打包過程也隨之消失了。相比之下，在當今的互聯網裏，Docker鏡像須要的操做系統文件和目錄，可謂唾手可得。

因此，你只須要提供一個下載好的操做系統文件與目錄，而後使用它製做一個壓縮包便可，這個命令就是：

$ docker build "個人鏡像"複製代碼

一旦鏡像製做完成，用戶就可讓Docker建立一個「沙盒」來解壓這個鏡像，而後在「沙盒」中運行本身的應用，這個命令就是：

$ docker run "個人鏡像"複製代碼

固然，docker run建立的「沙盒」，也是使用Cgroups和Namespace機制建立出來的隔離環境。我會在後面的文章中，詳細介紹這個機制的實現原理。

因此，Docker項目給PaaS世界帶來的「降維打擊」，實際上是提供了一種很是便利的打包機制。這種機制直接打包了應用運行所須要的整個操做系統，從而保證了本地環境和雲端環境的高度一致，避免了用戶經過「試錯」來匹配兩種不一樣運行環境之間差別的痛苦過程。

而對於開發者們來講，在終於體驗到了生產力解放所帶來的痛快以後，他們天然選擇了用腳投票，直接宣告了PaaS時代的結束。

不過，Docker項目當然解決了應用打包的難題，但正如前面所介紹的那樣，它並不能代替PaaS完成大規模部署應用的職責。

遺憾的是，考慮到Docker公司是一個與本身有潛在競爭關係的商業實體，再加上對Docker項目普及程度的錯誤判斷，Cloud Foundry項目並無第一時間使用Docker做爲本身的核心依賴，去替換本身那套飽受詬病的打包流程。

反卻是一些機敏的創業公司，紛紛在第一時間推出了Docker容器集羣管理的開源項目（好比Deis和Flynn），它們通常稱本身爲CaaS，即Container-as-a-Service，用來跟「過期」的PaaS們劃清界限（這裏做者重複了最後幾個字，須要剪掉）。

而在2014年末的DockerCon上，Docker公司雄心勃勃地對外發布了自家研發的「Docker原生」容器集羣管理項目Swarm，不只將這波「CaaS」熱推向了一個史無前例的高潮，更是寄託了整個Docker公司從新定義PaaS的宏偉願望。

在2014年的這段巔峯歲月裏，Docker公司離本身的理想真的只有一步之遙。