01 | 預(yù)習(xí)篇 · 小鯨魚(yú)大事記（一）：初出茅廬

2018-08-28?張磊

01 | 預(yù)習(xí)篇 · 小鯨魚(yú)大事記（一）：初出茅廬

朗讀人：張磊????12′11′′ | 5.59M

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

如果我問(wèn)你，現(xiàn)今最熱門(mén)的服務(wù)器端技術(shù)是什么？想必你不假思索就能回答上來(lái)：當(dāng)然是容器！可是，如果現(xiàn)在不是 2018 年而是 2013 年，你的回答還能這么斬釘截鐵么？

現(xiàn)在就讓我們把時(shí)間撥回到五年前去看看吧。

2013 年的后端技術(shù)領(lǐng)域，已經(jīng)太久沒(méi)有出現(xiàn)過(guò)令人興奮的東西了。曾經(jīng)被人們寄予厚望的云計(jì)算技術(shù)，也已經(jīng)從當(dāng)初虛無(wú)縹緲的概念蛻變成了實(shí)實(shí)在在的虛擬機(jī)和賬單。而相比于的如日中天 AWS 和盛極一時(shí)的 OpenStack，以 Cloud Foundry 為代表的開(kāi)源 PaaS 項(xiàng)目，卻成為了當(dāng)時(shí)云計(jì)算技術(shù)中的一股清流。

這時(shí)，Cloud Foundry 項(xiàng)目已經(jīng)基本度過(guò)了最艱難的概念普及和用戶(hù)教育階段，吸引了包括百度、京東、華為、IBM 等一大批國(guó)內(nèi)外技術(shù)廠商，開(kāi)啟了以開(kāi)源 PaaS 為核心構(gòu)建平臺(tái)層服務(wù)能力的變革。如果你有機(jī)會(huì)問(wèn)問(wèn)當(dāng)時(shí)的云計(jì)算從業(yè)者們，他們十有八九都會(huì)告訴你：PaaS 的時(shí)代就要來(lái)了！

這個(gè)說(shuō)法其實(shí)一點(diǎn)兒沒(méi)錯(cuò)，如果不是后來(lái)一個(gè)叫 Docker 的開(kāi)源項(xiàng)目突然冒出來(lái)的話。

事實(shí)上，當(dāng)時(shí)還名叫 dotCloud 的 Docker 公司，也是這股 PaaS 熱潮中的一份子。只不過(guò)相比于 Heroku、Pivotal、Red Hat 等 PaaS 弄潮兒們，dotCloud 公司實(shí)在是太微不足道了，而它的主打產(chǎn)品由于跟主流的 Cloud Foundry 社區(qū)脫節(jié)，長(zhǎng)期以來(lái)也無(wú)人問(wèn)津。眼看就要被如火如荼的 PaaS 風(fēng)潮拋棄，dotCloud 公司卻做出了這樣一個(gè)決定：開(kāi)源自己的容器項(xiàng)目 Docker。

顯然，這個(gè)決定在當(dāng)時(shí)根本沒(méi)人在乎。

“容器”這個(gè)概念從來(lái)就不是什么新鮮的東西，也不是 Docker 公司發(fā)明的。即使在當(dāng)時(shí)最熱門(mén)的 PaaS 項(xiàng)目 Cloud Foundry 中，容器也只是其最底層、最沒(méi)人關(guān)注的那一部分。說(shuō)到這里，我正好以當(dāng)時(shí)的事實(shí)標(biāo)準(zhǔn) Cloud Foundry 為例，來(lái)解說(shuō)一下 PaaS 技術(shù)。

PaaS 項(xiàng)目被大家接納的一個(gè)主要原因，就是它提供了一種名叫“應(yīng)用托管”的能力。?在當(dāng)時(shí)，虛擬機(jī)和云計(jì)算已經(jīng)是比較普遍的技術(shù)和服務(wù)了，那時(shí)主流用戶(hù)的普遍用法，就是租一批 AWS 或者 OpenStack 的虛擬機(jī)，然后像以前管理物理服務(wù)器那樣，用腳本或者手工的方式在這些機(jī)器上部署應(yīng)用。

當(dāng)然，這個(gè)部署過(guò)程難免會(huì)碰到云端虛擬機(jī)和本地環(huán)境不一致的問(wèn)題，所以當(dāng)時(shí)的云計(jì)算服務(wù)，比的就是誰(shuí)能更好地模擬本地服務(wù)器環(huán)境，能帶來(lái)更好的“上云”體驗(yàn)。而 PaaS 開(kāi)源項(xiàng)目的出現(xiàn)，就是當(dāng)時(shí)解決這個(gè)問(wèn)題的一個(gè)最佳方案。

舉個(gè)例子，虛擬機(jī)創(chuàng)建好之后，運(yùn)維人員只需要在這些機(jī)器上部署一個(gè) Cloud Foundry 項(xiàng)目，然后開(kāi)發(fā)者只要執(zhí)行一條命令就能把本地的應(yīng)用部署到云上，這條命令就是：

$ cf push " 我的應(yīng)用 "

是不是很神奇？

事實(shí)上，像 Cloud Foundry 這樣的 PaaS 項(xiàng)目，最核心的組件就是一套應(yīng)用的打包和分發(fā)機(jī)制。?Cloud Foundry 為每種主流編程語(yǔ)言都定義了一種打包格式，而“cf push”的作用，基本上等同于用戶(hù)把應(yīng)用的可執(zhí)行文件和啟動(dòng)腳本打進(jìn)一個(gè)壓縮包內(nèi)，上傳到云上 Cloud Foundry 的存儲(chǔ)中。接著，Cloud Foundry 會(huì)通過(guò)調(diào)度器選擇一個(gè)可以運(yùn)行這個(gè)應(yīng)用的虛擬機(jī)，然后通知這個(gè)機(jī)器上的 Agent 把應(yīng)用壓縮包下載下來(lái)啟動(dòng)。

這時(shí)候關(guān)鍵來(lái)了，由于需要在一個(gè)虛擬機(jī)上啟動(dòng)很多個(gè)來(lái)自不同用戶(hù)的應(yīng)用，Cloud Foundry 會(huì)調(diào)用操作系統(tǒng)的 Cgroups 和 Namespace 機(jī)制為每一個(gè)應(yīng)用單獨(dú)創(chuàng)建一個(gè)稱(chēng)作“沙盒”的隔離環(huán)境，然后在“沙盒”中啟動(dòng)這些應(yīng)用進(jìn)程。這樣，就實(shí)現(xiàn)了把多個(gè)用戶(hù)的應(yīng)用互不干涉地在虛擬機(jī)里批量地、自動(dòng)地運(yùn)行起來(lái)的目的。

這，正是 PaaS 項(xiàng)目最核心的能力。?而這些 Cloud Foundry 用來(lái)運(yùn)行應(yīng)用的隔離環(huán)境，或者說(shuō)“沙盒”，就是所謂的“容器”。

而 Docker 項(xiàng)目，實(shí)際上跟 Cloud Foundry 的容器并沒(méi)有太大不同，所以在它發(fā)布后不久，Cloud Foundry 的首席產(chǎn)品經(jīng)理 James Bayer 就在社區(qū)里做了一次詳細(xì)對(duì)比，告訴用戶(hù) Docker 實(shí)際上只是一個(gè)同樣使用 Cgroups 和 Namespace 實(shí)現(xiàn)的“沙盒”而已，沒(méi)有什么特別的黑科技，也不需要特別關(guān)注。

然而，短短幾個(gè)月，Docker 項(xiàng)目就迅速崛起了。它的崛起速度如此之快，以至于 Cloud Foundry 以及所有的 PaaS 社區(qū)還沒(méi)來(lái)得及成為它的競(jìng)爭(zhēng)對(duì)手，就直接被宣告出局了。那時(shí)候，一位多年的 PaaS 從業(yè)者曾經(jīng)如此感慨道：這簡(jiǎn)直就是一場(chǎng)“降維打擊”啊。

難道這一次，連闖蕩多年的“老江湖”James Bayer 也看走眼了么？

并沒(méi)有。

事實(shí)上，Docker 項(xiàng)目確實(shí)與 Cloud Foundry 的容器在大部分功能和實(shí)現(xiàn)原理上都是一樣的，可偏偏就是這剩下的一小部分不一樣的功能，成了 Docker 項(xiàng)目接下來(lái)“呼風(fēng)喚雨”的不二法寶。

這個(gè)功能，就是 Docker 鏡像。

恐怕連 Docker 項(xiàng)目的作者 Solomon Hykes 自己當(dāng)時(shí)都沒(méi)想到，這個(gè)小小的創(chuàng)新，在短短幾年內(nèi)就如此迅速地改變了整個(gè)云計(jì)算領(lǐng)域的發(fā)展歷程。

我前面已經(jīng)介紹過(guò)，PaaS 之所以能夠幫助用戶(hù)大規(guī)模部署應(yīng)用到集群里，是因?yàn)樗峁┝艘惶讘?yīng)用打包的功能?？善褪沁@個(gè)打包功能，卻成了 PaaS 日后不斷遭到用戶(hù)詬病的一個(gè)“軟肋”。

出現(xiàn)這個(gè)問(wèn)題的根本原因是，一旦用上了 PaaS，用戶(hù)就必須為每種語(yǔ)言、每種框架，甚至每個(gè)版本的應(yīng)用維護(hù)一個(gè)打好的包。這個(gè)打包過(guò)程，沒(méi)有任何章法可循，更麻煩的是，明明在本地運(yùn)行得好好的應(yīng)用，卻需要做很多修改和配置工作才能在 PaaS 里運(yùn)行起來(lái)。而這些修改和配置，并沒(méi)有什么經(jīng)驗(yàn)可以借鑒，基本上得靠不斷試錯(cuò)，直到你摸清楚了本地應(yīng)用和遠(yuǎn)端 PaaS 匹配的“脾氣”才能夠搞定。

最后結(jié)局就是，“cf push”確實(shí)是能一鍵部署了，但是為了實(shí)現(xiàn)這個(gè)一鍵部署，用戶(hù)為每個(gè)應(yīng)用打包的工作可謂一波三折，費(fèi)盡心機(jī)。

而Docker 鏡像解決的，恰恰就是打包這個(gè)根本性的問(wèn)題。?所謂 Docker 鏡像，其實(shí)就是一個(gè)壓縮包。但是這個(gè)壓縮包里的內(nèi)容，比 PaaS 的應(yīng)用可執(zhí)行文件 + 啟停腳本的組合就要豐富多了。實(shí)際上，大多數(shù) Docker 鏡像是直接由一個(gè)完整操作系統(tǒng)的所有文件和目錄構(gòu)成的，所以這個(gè)壓縮包里的內(nèi)容跟你本地開(kāi)發(fā)和測(cè)試環(huán)境用的操作系統(tǒng)是完全一樣的。

這就有意思了：假設(shè)你的應(yīng)用在本地運(yùn)行時(shí)，能看見(jiàn)的環(huán)境是 CentOS 7.2 操作系統(tǒng)的所有文件和目錄，那么只要用 CentOS 7.2 的 ISO 做一個(gè)壓縮包，再把你的應(yīng)用可執(zhí)行文件也壓縮進(jìn)去，那么無(wú)論在哪里解壓這個(gè)壓縮包，都可以得到與你本地測(cè)試時(shí)一樣的環(huán)境。當(dāng)然，你的應(yīng)用也在里面！

這就是 Docker 鏡像最厲害的地方：只要有這個(gè)壓縮包在手，你就可以使用某種技術(shù)創(chuàng)建一個(gè)“沙盒”，在“沙盒”中解壓這個(gè)壓縮包，然后就可以運(yùn)行你的程序了。

更重要的是，這個(gè)壓縮包包含了完整的操作系統(tǒng)文件和目錄，也就是包含了這個(gè)應(yīng)用運(yùn)行所需要的所有依賴(lài)，所以你可以先用這個(gè)壓縮包在本地進(jìn)行開(kāi)發(fā)和測(cè)試，完成之后，再把這個(gè)壓縮包上傳到云端運(yùn)行。

在這個(gè)過(guò)程中，你完全不需要進(jìn)行任何配置或者修改，因?yàn)檫@個(gè)壓縮包賦予了你一種極其寶貴的能力：本地環(huán)境和云端環(huán)境的高度一致！

這，正是 Docker 鏡像的精髓。

那么，有了 Docker 鏡像這個(gè)利器，PaaS 里最核心的打包系統(tǒng)一下子就沒(méi)了用武之地，最讓用戶(hù)抓狂的打包過(guò)程也隨之消失了。相比之下，在當(dāng)今的互聯(lián)網(wǎng)里，Docker 鏡像需要的操作系統(tǒng)文件和目錄，可謂唾手可得。

所以，你只需要提供一個(gè)下載好的操作系統(tǒng)文件與目錄，然后使用它制作一個(gè)壓縮包即可，這個(gè)命令就是：

$ docker build " 我的鏡像 "

一旦鏡像制作完成，用戶(hù)就可以讓 Docker 創(chuàng)建一個(gè)“沙盒”來(lái)解壓這個(gè)鏡像，然后在“沙盒”中運(yùn)行自己的應(yīng)用，這個(gè)命令就是：

$ docker run " 我的鏡像 "

當(dāng)然，docker run 創(chuàng)建的“沙盒”，也是使用 Cgroups 和 Namespace 機(jī)制創(chuàng)建出來(lái)的隔離環(huán)境。我會(huì)在后面的文章中，詳細(xì)介紹這個(gè)機(jī)制的實(shí)現(xiàn)原理。

所以，Docker 項(xiàng)目給 PaaS 世界帶來(lái)的“降維打擊”，其實(shí)是提供了一種非常便利的打包機(jī)制。這種機(jī)制直接打包了應(yīng)用運(yùn)行所需要的整個(gè)操作系統(tǒng)，從而保證了本地環(huán)境和云端環(huán)境的高度一致，避免了用戶(hù)通過(guò)“試錯(cuò)”來(lái)匹配兩種不同運(yùn)行環(huán)境之間差異的痛苦過(guò)程。

而對(duì)于開(kāi)發(fā)者們來(lái)說(shuō)，在終于體驗(yàn)到了生產(chǎn)力解放所帶來(lái)的痛快之后，他們自然選擇了用腳投票，直接宣告了 PaaS 時(shí)代的結(jié)束。

不過(guò)，Docker 項(xiàng)目固然解決了應(yīng)用打包的難題，但正如前面所介紹的那樣，它并不能代替 PaaS 完成大規(guī)模部署應(yīng)用的職責(zé)。

遺憾的是，考慮到 Docker 公司是一個(gè)與自己有潛在競(jìng)爭(zhēng)關(guān)系的商業(yè)實(shí)體，再加上對(duì) Docker 項(xiàng)目普及程度的錯(cuò)誤判斷，Cloud Foundry 項(xiàng)目并沒(méi)有第一時(shí)間使用 Docker 作為自己的核心依賴(lài)，去替換自己那套飽受詬病的打包流程。

反倒是一些機(jī)敏的創(chuàng)業(yè)公司，紛紛在第一時(shí)間推出了 Docker 容器集群管理的開(kāi)源項(xiàng)目（比如 Deis 和 Flynn），它們一般稱(chēng)自己為 CaaS，即 Container-as-a-Service，用來(lái)跟“過(guò)時(shí)”的 PaaS 們劃清界限。

而在 2014 年底的 DockerCon 上，Docker 公司雄心勃勃地對(duì)外發(fā)布了自家研發(fā)的“Docker 原生”容器集群管理項(xiàng)目 Swarm，不僅將這波“CaaS”熱推向了一個(gè)前所未有的高潮，更是寄托了整個(gè) Docker 公司重新定義 PaaS 的宏偉愿望。

在 2014 年的這段巔峰歲月里，Docker 公司離自己的理想真的只有一步之遙。

總結(jié)

2013~2014 年，以 Cloud Foundry 為代表的 PaaS 項(xiàng)目，逐漸完成了教育用戶(hù)和開(kāi)拓市場(chǎng)的艱巨任務(wù)，也正是在這個(gè)將概念逐漸落地的過(guò)程中，應(yīng)用“打包”困難這個(gè)問(wèn)題，成了整個(gè)后端技術(shù)圈子的一塊心病。

Docker 項(xiàng)目的出現(xiàn)，則為這個(gè)根本性的問(wèn)題提供了一個(gè)近乎完美的解決方案。這正是 Docker 項(xiàng)目剛剛開(kāi)源不久，就能夠帶領(lǐng)一家原本默默無(wú)聞的 PaaS 創(chuàng)業(yè)公司脫穎而出，然后迅速占領(lǐng)了所有云計(jì)算領(lǐng)域頭條的技術(shù)原因。

而在成為了基礎(chǔ)設(shè)施領(lǐng)域近十年難得一見(jiàn)的技術(shù)明星之后，dotCloud 公司則在 2013 年底大膽改名為 Docker 公司。不過(guò)，這個(gè)在當(dāng)時(shí)就頗具爭(zhēng)議的改名舉動(dòng)，也成為了日后容器技術(shù)圈風(fēng)云變幻的一個(gè)關(guān)鍵伏筆。

思考題

你是否曾經(jīng)研發(fā)過(guò)類(lèi)似 PaaS 的項(xiàng)目？你碰到過(guò)應(yīng)用打包的問(wèn)題嗎，又是如何解決的呢？

感謝收聽(tīng)，歡迎你給我留言，也歡迎分享給更多的朋友一起閱讀。