容器!容器!

回溯歷史源頭

相比於盛極一時的

• AWS
• OpenStack
• 以Cloud Foundry為代表的PaaS專案，卻成了當時雲端計算技術中的一股清流 Cloud Foundry專案已經基本度過了最艱難的概念普及和使用者教育階段，開啟了以開源PaaS為核心構建平臺層服務能力的變革

只是,後來一個叫 Docker 的開源專案橫空出世

當時還名叫dotCloud的Docker公司，也是PaaS熱潮中的一員

相比於Heroku、Pivotal、Red Hat等PaaS新寵，dotCloud微不足道，主打產品跟主流的Cloud Foundry社群脫節，門可羅雀!

dotCloud公司突然決定：開源自己的容器專案 Docker

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

“容器”這個概念從來就不是什麼新鮮的東西，也不是Docker公司發明的。

即使在當時最熱門的PaaS專案Cloud Foundry中，容器也只是其最底層、最沒人關注的那一部分。

PaaS專案被大家接納的一個主要原因是它提供“應用託管”能力

那時主流使用者的普遍用法，就是租一批AWS或者OpenStack的虛擬機器，然後像以前管理物理伺服器那樣，用指令碼或者手工的方式在這些機器上部署應用。

當然，部署過程難免碰到雲端虛擬機器和本地環境不一致問題，當時的雲端計算服務，比的就是誰能更好模擬本地伺服器環境，帶來更好“上雲”體驗。

而PaaS開源專案的出現，就是當時解決這個問題的一個最佳方案。

虛擬機器建立後，運維只需在這些機器上部署一個Cloud Foundry專案

然後開發者只要執行一條命令就能把本地的應用部署到雲上

cf push "My APP"

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社群還沒來得及成為它的競爭對手，就直接出局

Docker專案確實與Cloud Foundry的容器在大部分功能和實現原理上都是一樣的，可偏偏就是這剩下的一小部分不一樣的功能，成了Docker專案接下來“呼風喚雨”的不二法寶。

Docker映象

恐怕連Docker專案作者都沒想到，這個小小的創新，在短短几年內就如此迅速地改變了整個雲端計算領域的發展歷程。

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提供了一種非常便利的打包機制。直接打包了應用執行所需要的整個作業系統，保證了本地環境和雲端環境的高度一致，避免了使用者通過“試錯”來匹配兩種不同執行環境之間差異的痛苦過程。

不過，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公司離自己的理想真的只有一步之遙。

總結

2013~2014年，以Cloud Foundry為代表的PaaS專案，逐漸完成了教育使用者和開拓市場的艱鉅任務，也正是在這個將概念逐漸落地的過程中，應用“打包”困難這個問題，成了整個後端技術圈子的一塊心病。

Docker專案的出現，則為這個根本性的問題提供了一個近乎完美的解決方案。這正是Docker專案剛剛開源不久，就能夠帶領一家原本默默無聞的PaaS創業公司脫穎而出，然後迅速佔領了所有云計算領域頭條的技術原因。

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

參考

• docker官網
• Docker實戰
• 深入