容器!容器!
回溯歷史源頭
相比於盛極一時的
- 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實戰
- 深入剖析Kubernetes