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

如果我問你，現(xiàn)今最熱門的服務(wù)器端技術(shù)是什么？想必你不假思索就能回答上來：當(dāng)然是容器！

可是，如果現(xiàn)在不是 2018 年而是 2013 年，你的回答還能這么斬釘截鐵么？

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

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

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

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

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

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

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

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

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

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

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

是不是很神奇？

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

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

這，正是 PaaS 項(xiàng)目最核心的能力。而這些 Cloud Foundry 用來運(yùn)行應(yīng)用的隔離環(huán)境，或者

說“沙盒”，就是所謂的“容器”。

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

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

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

并沒有。

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

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

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

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

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

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

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

這就有意思了：假設(shè)你的應(yīng)用在本地運(yùn)行時(shí)，能看見的環(huán)境是 CentOS 7.2 操作系統(tǒng)的所有文件和目錄，那么只要用 CentOS 7.2 的 ISO 做一個(gè)壓縮包，再把你的應(yīng)用可執(zhí)行文件也壓縮進(jìn)去，那么無論在哪里解壓這個(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)行所需要的所有依賴，所以你可以先用這個(gè)壓縮包在本地進(jìn)行開發(fā)和測(cè)試，完成之后，再把這個(gè)壓縮包上傳到云端運(yùn)行。

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

這，正是 Docker 鏡像的精髓。

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

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

1 $ docker build " 我的鏡像"

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

1 $ docker run " 我的鏡像"

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

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

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

不過，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)目并沒有第一時(shí)間使用 Docker 作為自己的核心依賴，去替換自己那套飽受詬病的打包流程。

反倒是一些機(jī)敏的創(chuàng)業(yè)公司，紛紛在第一時(shí)間推出了 Docker 容器集群管理的開源項(xiàng)目（比如Deis 和 Flynn），它們一般稱自己為 CaaS，即 Container-as-a-Service，用來跟“過時(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)目，逐漸完成了教育用戶和開拓市場(chǎng)的艱巨任務(wù)，也正是在這個(gè)將概念逐漸落地的過程中，應(yīng)用“打包”困難這個(gè)問題，成了整個(gè)后端技術(shù)圈子的一塊心病。

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

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

思考題

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

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

文章回復(fù)：

重復(fù)打包，重復(fù)配置，換了運(yùn)行環(huán)境，你就不得不再來一遍。我們創(chuàng)建了適用于一個(gè)應(yīng)用的部署模式，但我們僅僅只是創(chuàng)建的它，并不能批量生產(chǎn)它。Docker的出現(xiàn)，好比告訴我們：“你應(yīng)該用你的模板去快速的批量生產(chǎn)，而不是按照這個(gè)模板再‘創(chuàng)造’一個(gè)一樣的模板”

2018-08-28

fantasticL

引用原文：“docker項(xiàng)目給PaaS世界帶來的“降維打擊”，其實(shí)是提供了一種非常便利的打包機(jī)制。這種機(jī)制直接打包了應(yīng)用運(yùn)行所需要的整個(gè)操作系統(tǒng)，從而保證了本地環(huán)境和云端環(huán)境的高度一致”既然打包了整個(gè)操作系統(tǒng)，如果一臺(tái)機(jī)器上跑n個(gè)docker鏡像，那意味著有n個(gè)操作系統(tǒng)運(yùn)行在這臺(tái)機(jī)器上，那每個(gè)docker所能獲取到的資源是不是就很有限了，比如內(nèi)存、cpu、文件描述符等等，請(qǐng)釋惑。謝謝

2018/11/17

作者回復(fù)

其實(shí)只打包了文件系統(tǒng)，不包括操作系統(tǒng)內(nèi)核。在容器技術(shù)基礎(chǔ)里我們會(huì)詳細(xì)解釋。

2018-08-28

timmy

一個(gè)弱智的問題：打包了系統(tǒng)鏡像的應(yīng)用會(huì)不會(huì)超級(jí)大？

2018-08-28

作者回復(fù)

會(huì)，不過講鏡像的時(shí)候會(huì)提到，怎么個(gè)大法

2018-08-28

@特

在接觸Docker以前主要是使用自動(dòng)化腳本去做一系列重復(fù)的環(huán)境初始化工作，比如大名鼎鼎的LAMP就有公司專門為其打造了自動(dòng)化安裝的系統(tǒng)。后來就有了ansible這種神器。但是他們都不如Docker這么簡(jiǎn)潔粗暴。

2018-08-28

李博越

后面求加餐能講講cncf各個(gè)產(chǎn)品的overview以及關(guān)系

2018-08-28

作者回復(fù)

最后一部分開源生態(tài)，自會(huì)提到

2018-08-28

方志朋

公司的paas系統(tǒng)從swarm轉(zhuǎn)到了k8s，剛好看到了這個(gè)專欄，內(nèi)心十分的激動(dòng)，看了兩篇，內(nèi)容十分的精彩。

2018-08-28

歲月～靜好

作為菜鳥的我希望之后可以在自己工作中搭建應(yīng)用起來Docker和k8s。

2018-08-28

作者回復(fù)

先考慮小規(guī)模試點(diǎn)。

2018-08-28

adoal

如果打包不包括kernel，那么某個(gè)應(yīng)用需要加載特定ko怎么辦呢？

2018-09-16

作者回復(fù)

沒辦法，不能用常規(guī)的linux容器

2018-09-17

李金洋

buildpacks是不同語言，不同版本都要有一個(gè)，確實(shí)很煩。

2018-09-06

張應(yīng)羅

一直對(duì)YAML文件里的 list格式 理解的不深入，以及 selector 和label 關(guān)系等，后面會(huì)有涉及嘛？包括CICD的流程等

2018-08-28

作者回復(fù)

重要字段都會(huì)做詳細(xì)解釋

2018-08-28

剃刀嗎啡

我個(gè)人理解用戶還是需要Paas作為“云”，也就是載體，在之上運(yùn)行這個(gè)“包”。這也就是AWS還是活的好好的原因。不知道對(duì)不對(duì)請(qǐng)老師指正。

2018-08-28

作者回復(fù)

一點(diǎn)沒錯(cuò)。不過，我們也會(huì)講到一些新技術(shù)，讓AWS們也有點(diǎn)坐不住

2018-08-28

leon

一直比較糾結(jié)，生產(chǎn)環(huán)境建議是二進(jìn)制還是容器方式部署？

2018-08-28

作者回復(fù)

部署部分會(huì)講到最佳實(shí)踐

2018-08-28

wangbo

容器和阿里云這些服務(wù)器有什么關(guān)系嗎？這個(gè)我一直沒搞懂

2018-08-28

作者回復(fù)

可以認(rèn)為沒關(guān)系，容器就是容器，是應(yīng)用封裝的小伙伴

2018-08-28

chen

會(huì)有容器網(wǎng)絡(luò)相關(guān)知識(shí)點(diǎn)嗎？

2018-08-28

作者回復(fù)

當(dāng)然，這是重點(diǎn)之一

2018-08-28

沒經(jīng)歷過pass階段, 既然打包這么重要，為啥后來的docker做了，cloud foundry自己沒有做？有什么特別的難點(diǎn)嗎？

2018-08-28

作者回復(fù)

技術(shù)上其實(shí)不難，但要想出鏡像這個(gè)方法，卻是一個(gè)從0到1的突破。

2018-08-28

旭東

Devops和Docker的發(fā)展關(guān)系會(huì)有講嗎？微服務(wù)發(fā)展需求促成了Debops的發(fā)展，而Docker促進(jìn)了微服務(wù)的Devops。個(gè)人的理解不知對(duì)否

2018-08-28

作者回復(fù)

docker對(duì)devops的落地確實(shí)起到了真正落實(shí)的作用。不過篇幅所限，這一期主要關(guān)注打基礎(chǔ)，devops構(gòu)建屬于更上層的能力了。

2018-08-28

Wings

這個(gè)容器可以部署像tomcat那樣的常規(guī)JAVA項(xiàng)目么？JAVA程序猿表示不理解docker技術(shù)的應(yīng)用場(chǎng)景是否與JAVAWeb相關(guān)

2018-10-22

作者回復(fù)

與編程語言無關(guān)

2018-10-23

風(fēng)語者

也有說法認(rèn)為開發(fā)人員在Kubernetes的體驗(yàn)比較糟糕，畢竟通常Kubernetes被認(rèn)為更像是“IaaS+”而不是一個(gè)“PaaS”。如果Kubernetes就是“IaaS+”而不是一個(gè)“PaaS”，那是不是可以將Cloud Foundry運(yùn)行在Kubernetes之上？目前Cloud Founfry已經(jīng)支持了兩種不同的運(yùn)行時(shí)，參考:

Cloud Foundry gives you the choice: CF Container Runtime is built usingKubernetes and CF BOSH. You can also continue to use the Cloud Foundry cloudapplication platform —CF Application Runtime.

Kubernetes項(xiàng)目就是之前的Kubo項(xiàng)目發(fā)展而來。

Formerly known as Project Kubo, an incubating project within the CloudFoundry Foundation initiated by engineers at Google and Pivotal, theKubernetes-powered, Kubernetes-certified CF Container Runtime offers a uniform way to instantiate,deploy, andmanage highly available Kubernetes clusters on a cloud platform using CFBOSH.

這樣的整合看上去是取長(zhǎng)補(bǔ)短的結(jié)合，把Cloud Foundry作為PaaS管理整個(gè)應(yīng)用的云環(huán)境，包括k8s集群.

Kubernetesand CF BOSH together are a powerful combination. With CF BOSH managing thedeployment and lifecycle of your environment, you can achieve high availability forKubernetes clusters, as well as scaling, VM healing, and rolling upgrades.

因?yàn)槲业墓ぷ髦兄饕腔贑loud Foundry的開發(fā)，但同時(shí)對(duì)k8s非常感興趣，不知道這個(gè)整合的方向是否與以后的趨勢(shì)相悖，望指點(diǎn)迷津。

謝謝！

2018-10-12

作者回復(fù)

兩者沒什么聯(lián)系，也沒有取長(zhǎng)補(bǔ)短。cloudfoundry是標(biāo)準(zhǔn)的paas項(xiàng)目。kubernetes是容器化基礎(chǔ)設(shè)設(shè)施項(xiàng)目。根據(jù)需要選擇即可。

2018-10-12

jinbing

09年的時(shí)候就在做應(yīng)用打包，無數(shù)的腳本和接口，非常復(fù)雜，ISV的動(dòng)力也不足。容器用粗暴的方法（應(yīng)用連runtime環(huán)境一起打包）解決了這個(gè)問題。要是容器申請(qǐng)了專利，就不會(huì)發(fā)展這么快了吧。開源和商業(yè)專利相愛相殺啊~~

2018-10-09

洛子墟

阿里開源的PouchContainer和現(xiàn)有的K8s 區(qū)別大嗎?

2018-09-25

作者回復(fù)

一個(gè)是容器，一個(gè)是編排項(xiàng)目，這是天和地的區(qū)別……