現(xiàn)今最熱門的服務(wù)器端技術(shù)是容器！
可是，如果現(xiàn)在不是2018年而是2013年，你的回答還能這么斬釘截鐵么？現(xiàn)在就讓我們把時間撥回到五年前去看看吧。
相比于如日中天的書AWS和盛極一時的OpenStack，以Cloud Foundry為代表的開源PaaS項(xiàng)目，卻成為了當(dāng)時云計(jì)算技術(shù)中的一股清流。
這時，Cloud Foundry項(xiàng)目已經(jīng)基本度過了最艱難的概念普及和用戶教育階段，開啟了以開源PaaS為核心構(gòu)建平臺層服務(wù)能力的變革
這個說法其實(shí)一點(diǎn)兒沒錯
如果不是后來一個叫Docker的開源項(xiàng)目突然冒出來的話。
當(dāng)時還名叫dotCloud的Docker公司，也是PaaS熱潮中的一子。只不過相比于Heroku、Pivotal、Red Hat等PaaS弄潮兒，dotCloud實(shí)在是微不足道，它的主打產(chǎn)品跟主流的Cloud Foundry社區(qū)脫節(jié)，長期以來無人問津。
眼看就要被如火如荼的PaaS風(fēng)潮拋棄，dotCloud公司卻做出了這樣一個決定：開源自己的容器項(xiàng)目Docker?。?！
顯然，這個決定在當(dāng)時根本沒人在乎。
“容器”這個概念從來就不是什么新鮮的東西，也不是Docker公司發(fā)明的。
即使在當(dāng)時最熱門的PaaS項(xiàng)目Cloud Foundry中，容器也只是其最底層、最沒人關(guān)注的那一部分。
PaaS項(xiàng)目被大家接納的一個主要原因是它提供“應(yīng)用托管”能力。
在當(dāng)時，虛擬機(jī)和云計(jì)算已經(jīng)是比較普遍的技術(shù)和服務(wù)了，那時主流用戶的普遍用法，就是租一批AWS或者OpenStack的虛擬機(jī)，然后像以前管理物理服務(wù)器那樣，用腳本或者手工的方式在這些機(jī)器上部署應(yīng)用。
當(dāng)然，部署過程難免碰到云端虛擬機(jī)和本地環(huán)境不一致問題，當(dāng)時的云計(jì)算服務(wù)，比的就是誰能更好模擬本地服務(wù)器環(huán)境，帶來更好“上云”體驗(yàn)。
而PaaS開源項(xiàng)目的出現(xiàn)，就是當(dāng)時解決這個問題的一個最佳方案。
虛擬機(jī)創(chuàng)建后，運(yùn)維只需在這些機(jī)器上部署一個Cloud Foundry項(xiàng)目，然后開發(fā)者只要執(zhí)行一條命令就能把本地的應(yīng)用部署到云上，這條命令就是：
$ cf push "我的應(yīng)用"
像Cloud Foundry這樣的PaaS項(xiàng)目，最核心的組件就是應(yīng)用的打包和分發(fā)機(jī)制。
Cloud Foundry為每種主流編程語言都定義了一種打包格式，“cf push”等同于用戶把應(yīng)用的可執(zhí)行文件和啟動腳本打進(jìn)一個壓縮包內(nèi)，上傳到云上Cloud Foundry的存儲中。
接著，Cloud Foundry會通過調(diào)度器選擇一個可以運(yùn)行這個應(yīng)用的虛擬機(jī)，然后通知這個機(jī)器上的Agent把應(yīng)用壓縮包下載下來啟動。
由于需要在一個虛擬機(jī)上啟動很多個來自不同用戶的應(yīng)用，Cloud Foundry會調(diào)用操作系統(tǒng)的Cgroups和Namespace機(jī)制為每一個應(yīng)用單獨(dú)創(chuàng)建一個稱作“沙盒”的隔離環(huán)境，然后在“沙盒”中啟動這些應(yīng)用進(jìn)程。這樣，就實(shí)現(xiàn)了把多個用戶的應(yīng)用互不干涉地在虛擬機(jī)里批量地、自動地運(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ì)對比，告訴用戶Docker實(shí)際上只是一個同樣使用Cgroups和Namespace實(shí)現(xiàn)的“沙盒”而已，沒有什么特別的黑科技，也不需要特別關(guān)注。
Docker項(xiàng)目迅速崛起。如此之快，以至于Cloud Foundry以及所有的PaaS社區(qū)還沒來得及成為它的競爭對手，就直接出局了
難道這一次，連闖蕩多年的“老江湖”James Bayer也看走眼了么？并沒有。
事實(shí)上，Docker項(xiàng)目確實(shí)與Cloud Foundry的容器在大部分功能和實(shí)現(xiàn)原理上都是一樣的，可偏偏就是這剩下的一小部分不一樣的功能，成了Docker項(xiàng)目接下來“呼風(fēng)喚雨”的不二法寶。
這個功能，就是Docker鏡像。
恐怕連Docker項(xiàng)目的作者Solomon Hykes自己當(dāng)時都沒想到，這個小小的創(chuàng)新，在短短幾年內(nèi)就如此迅速地改變了整個云計(jì)算領(lǐng)域的發(fā)展歷程。
PaaS之所以能夠幫助用戶大規(guī)模部署應(yīng)用到集群里，是因?yàn)樘峁┝艘惶讘?yīng)用打包的功能。偏偏打包功能，成了PaaS日后不斷遭到用戶詬病的一個“軟肋”。
出現(xiàn)這個問題的根本原因是，一旦用上了PaaS，用戶就必須為每種語言、每種框架，甚至每個版本的應(yīng)用維護(hù)一個打好的包。
這個打包過程，沒有任何章法可循，更麻煩的是，明明在本地運(yùn)行得好好的應(yīng)用，卻需要做很多修改和配置工作才能在PaaS里運(yùn)行起來。而這些修改和配置，并沒有什么經(jīng)驗(yàn)可以借鑒，基本上得靠不斷試錯，直到你摸清楚了本地應(yīng)用和遠(yuǎn)端PaaS匹配的“脾氣”才能夠搞定。
最后結(jié)局就是，“cf push”確實(shí)是能一鍵部署了，但是為了實(shí)現(xiàn)這個一鍵部署，用戶為每個應(yīng)用打包的工作可謂一波三折，費(fèi)盡心機(jī)。
而Docker鏡像解決的，恰恰就是打包這個根本性的問題。
所謂Docker鏡像，其實(shí)就是一個壓縮包。但是這個壓縮包里的內(nèi)容，比PaaS的應(yīng)用可執(zhí)行文件+啟停腳本的組合就要豐富多了。實(shí)際上，大多數(shù)Docker鏡像是直接由一個完整操作系統(tǒng)的所有文件和目錄構(gòu)成的，所以這個壓縮包里的內(nèi)容跟你本地開發(fā)和測試環(huán)境用的操作系統(tǒng)是完全一樣的。
假設(shè)你的應(yīng)用在本地運(yùn)行時，能看見的環(huán)境是CentOS 7.2操作系統(tǒng)的所有文件和目錄，那么只要用CentOS 7.2的ISO做一個壓縮包，再把你的應(yīng)用可執(zhí)行文件也壓縮進(jìn)去，那么無論在哪里解壓這個壓縮包，都可以得到與你本地測試時一樣的環(huán)境。當(dāng)然，你的應(yīng)用也在里面?。?！
這就是Docker鏡像最厲害的地方：只要有這個壓縮包在手，你就可以使用某種技術(shù)創(chuàng)建一個“沙盒”，在“沙盒”中解壓這個壓縮包，然后就可以運(yùn)行你的程序了。
更重要的是，這個壓縮包包含了完整的操作系統(tǒng)文件和目錄，也就是包含了這個應(yīng)用運(yùn)行所需要的所有依賴，所以你可以先用這個壓縮包在本地進(jìn)行開發(fā)和測試，完成之后，再把這個壓縮包上傳到云端運(yùn)行。在這個過程中，你完全不需要進(jìn)行任何配置或者修改，因?yàn)檫@個壓縮包賦予了你一種極其寶貴的能力：本地環(huán)境和云端環(huán)境的一致！
這，正是Docker鏡像的精髓。
有了Docker鏡像，PaaS里最核心的打包系統(tǒng)一下子就沒了用武之地，最讓用戶抓狂的打包過程也隨之消失了。
相比之下，在當(dāng)今的互聯(lián)網(wǎng)里，Docker鏡像需要的操作系統(tǒng)文件和目錄，可謂唾手可得。
所以，你只需要提供一個下載好的操作系統(tǒng)文件與目錄，然后使用它制作一個壓縮包即可，這個命令就是：
$ docker build "我的鏡像"
一旦鏡像制作完成，用戶就可以讓Docker創(chuàng)建一個“沙盒”來解壓這個鏡像，然后在“沙盒”中運(yùn)行自己的應(yīng)用，這個命令就是：
$ docker run "我的鏡像"
當(dāng)然，docker run創(chuàng)建的“沙盒”，也是使用Cgroups和Namespace機(jī)制創(chuàng)建出來的隔離環(huán)境
Docker提供了一種非常便利的打包機(jī)制。直接打包了應(yīng)用運(yùn)行所需要的整個操作系統(tǒng)，保證了本地環(huán)境和云端環(huán)境的高度一致，避免了用戶通過“試錯”來匹配兩種不同運(yùn)行環(huán)境之間差異的痛苦過程。
不過，Docker項(xiàng)目固然解決了應(yīng)用打包的難題，但正如前面所介紹的那樣，它并不能代替PaaS完成大規(guī)模部署應(yīng)用的職責(zé)。
遺憾的是，考慮到Docker公司是一個與自己有潛在競爭關(guān)系的商業(yè)實(shí)體，再加上對Docker項(xiàng)目普及程度的錯誤判斷，Cloud Foundry項(xiàng)目并沒有第一時間使用Docker作為自己的核心依賴，去替換自己那套飽受詬病的打包流程。
反倒是一些機(jī)敏的創(chuàng)業(yè)公司，紛紛在第一時間推出了Docker容器集群管理的開源項(xiàng)目（比如Deis和Flynn），它們一般稱自己為CaaS，即Container-as-a-Service，用來跟“過時”的PaaS們劃清界限。
而在2014年底的DockerCon上，Docker公司雄心勃勃地對外發(fā)布了自家研發(fā)的“Docker原生”容器集群管理項(xiàng)目Swarm，不僅將這波“CaaS”熱推向了一個前所未有的高潮，更是寄托了整個Docker公司重新定義PaaS的宏偉愿望。
在2014年的這段巔峰歲月里，Docker公司離自己的理想真的只有一步之遙。
總結(jié)
2013~2014年，以Cloud Foundry為代表的PaaS項(xiàng)目，逐漸完成了教育用戶和開拓市場的艱巨任務(wù)，也正是在這個將概念逐漸落地的過程中，應(yīng)用“打包”困難這個問題，成了整個后端技術(shù)圈子的一塊心病。
Docker項(xiàng)目的出現(xiàn)，則為這個根本性的問題提供了一個近乎完美的解決方案。這正是Docker項(xiàng)目剛剛開源不久，就能夠帶領(lǐng)一家原本默默無聞的PaaS創(chuàng)業(yè)公司脫穎而出，然后迅速占領(lǐng)了所有云計(jì)算領(lǐng)域頭條的技術(shù)原因。
而在成為了基礎(chǔ)設(shè)施領(lǐng)域近十年難得一見的技術(shù)明星之后，dotCloud公司則在2013年底大膽改名為Docker公司。不過，這個在當(dāng)時就頗具爭議的改名舉動，也成為了日后容器技術(shù)圈風(fēng)云變幻的一個關(guān)鍵伏筆。
參考
深入分析kubernates
