閱讀歷史：
PaaS:
從過去以物理機和虛擬機爲主體的開發運維環境，向以容器爲核心的基礎設施的轉變過程，並不是一次溫和的改革，而是涵蓋了對網絡、存儲、調度、操作系統、分佈式原理等各個方面的容器化理解和改造。
2013 年的後端技術領域，已經太久沒有出現過令人興奮的東西了。曾經被人們寄予厚望的雲計算技術，也已經從當初虛無縹緲的概念蛻變成了實實在在的虛擬機和賬單。而相比於如日中天 AWS 和盛極一時的 OpenStack，以 Cloud Foundry 爲代表的開源 PaaS 項目，卻成爲了當時雲計算技術中的一股清流。
當時，Cloud Foundry 項目已經基本度過了最艱難的概念普及和用戶教育階段，吸引了包括百度、京東、華爲、IBM 等一大批國內外技術廠商，開啓了以開源 PaaS 爲核心構建平臺層服務能力的變革。如果你有機會問問當時的雲計算從業者們，他們十有八九都會告訴你：PaaS 的時代就要來了！
這個說法其實一點兒沒錯，如果不是後來一個叫 Docker 的開源項目突然冒出來的話。
事實上，當時還名叫 dotCloud 的 Docker 公司，也是這股 PaaS 熱潮中的一份子。只不過相比於 Heroku、Pivotal、Red Hat 等 PaaS 弄潮兒們，dotCloud 公司實在是太微不足道了，而它的主打產品由於跟主流的 Cloud Foundry 社區脫節，長期以來也無人問津。眼看就要被如火如荼的 PaaS 風潮拋棄，dotCloud 公司卻做出了這樣一個決定：開源自己的容器項目 Docker。
顯然，這個決定在當時根本沒人在乎。
"容器"這個概念從來就不是什麼新鮮的東西，也不是 Docker 公司發明的。即使在當時最熱門的 PaaS 項目 Cloud Foundry 中，容器也只是其最底層、最沒人關注的那一部分。說到這裏，正好以當時的事實標準 Cloud Foundry 爲例，來解說一下 PaaS 技術。
PaaS 項目被大家接納的一個主要原因，就是它提供了一種名叫"應用託管"的能力。 在當時，虛擬機和雲計算已經是比較普遍的技術和服務了，那時主流用戶的普遍用法，就是租一批 AWS 或者 OpenStack 的虛擬機，然後像以前管理物理服務器那樣，用腳本或者手工的方式在這些機器上部署應用。
當然，這個部署過程難免會碰到雲端虛擬機和本地環境不一致的問題，所以當時的雲計算服務，比的就是誰能更好地模擬本地服務器環境，能帶來更好的"上雲"體驗。而 PaaS 開源項目的出現，就是當時解決這個問題的一個最佳方案。
舉個例子，虛擬機創建好之後，運維人員只需要在這些機器上部署一個 Cloud Foundry 項目，然後開發者只要執行一條命令就能把本地的應用部署到雲上，這條命令就是：
$ cf push " 我的應用 "
是不是很神奇？
事實上，像 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 社區還沒來得及成爲它的競爭對手，就直接被宣告出局了。那時候，一位多年的 PaaS 從業者曾經如此感慨道：這簡直就是一場"降維打擊"啊。
事實上，Docker 項目確實與 Cloud Foundry 的容器在大部分功能和實現原理上都是一樣的，可偏偏就是這剩下的一小部分不一樣的功能，成了 Docker 項目接下來"呼風喚雨"的不二法寶。
這個功能，就是 Docker 鏡像。
恐怕連 Docker 項目的作者 Solomon Hykes 自己當時都沒想到，這個小小的創新，在短短几年內就如此迅速地改變了整個雲計算領域的發展歷程。
前面已經介紹過，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 項目給 PaaS 世界帶來的"降維打擊"，其實是提供了一種非常便利的打包機制。這種機制直接打包了應用運行所需要的整個操作系統，從而保證了本地環境和雲端環境的高度一致，避免了用戶通過"試錯"來匹配兩種不同運行環境之間差異的痛苦過程。
而對於開發者們來說，在終於體驗到了生產力解放所帶來的痛快之後，他們自然選擇了用腳投票，直接宣告了 PaaS 時代的結束。
不過，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 公司。不過，這個在當時就頗具爭議的改名舉動，也成爲了日後容器技術圈風雲變幻的一個關鍵伏筆。
之前說到，伴隨着 PaaS 概念的逐步普及，以 Cloud Foundry 爲代表的經典 PaaS 項目，開始進入基礎設施領域的視野，平臺化和 PaaS 化成了這個生態中的一個最爲重要的進化趨勢。
就在對開源 PaaS 項目落地的不斷嘗試中，這個領域的從業者們發現了 PaaS 中最爲棘手也最亟待解決的一個問題：究竟如何給應用打包？
遺憾的是，無論是 Cloud Foundry、OpenShift，還是 Clodify，面對這個問題都沒能給出一個完美的答案，反而在競爭中走向了碎片化的歧途。
而就在這時，一個並不引人矚目的 PaaS 創業公司 dotCloud，卻選擇了開源自家的一個容器項目 Docker。更出人意料的是，就是這樣一個普通到不能再普通的技術，卻開啓了一個名爲"Docker"的全新時代。
Docker 項目的崛起，是不是偶然呢？這個以"鯨魚"爲註冊商標的技術創業公司，最重要的戰略之一就是：堅持把"開發者"羣體放在至高無上的位置。
相比於其他正在企業級市場裏廝殺得頭破血流的經典 PaaS 項目們，Docker 項目的推廣策略從一開始就呈現出一副"憨態可掬"的親人姿態，把每一位後端技術人員（而不是他們的老闆）作爲主要的傳播對象。
簡潔的 UI，有趣的 demo，“1 分鐘部署一個 WordPress 網站”“3 分鐘部署一個 Nginx 集羣”，這種同開發者之間與生俱來的親近關係，使 Docker 項目迅速成爲了全世界 Meetup 上最受歡迎的一顆新星。
在過去的很長一段時間裏，相較於前端和互聯網技術社區，服務器端技術社區一直是一個相對沉悶而小衆的圈子。在這裏，從事 Linux 內核開發的極客們自帶"不合羣"的"光環"，後端開發者們啃着多年不變的 TCP/IP 發着牢騷，運維更是天生註定的幕後英雄。
而 Docker 項目，卻給後端開發者提供了走向聚光燈的機會。就比如 Cgroups 和 Namespace 這種已經存在多年卻很少被人們關心的特性，在 2014 年和 2015 年竟然頻繁入選各大技術會議的分享議題，就因爲聽衆們想要知道 Docker 這個東西到底是怎麼一回事兒。
而 Docker 項目之所以能取得如此高的關注，一方面正如前面所說的那樣，它解決了應用打包和發佈這一困擾運維人員多年的技術難題；而另一方面，就是因爲它第一次把一個純後端的技術概念，通過非常友好的設計和封裝，交到了最廣大的開發者羣體手裏。
在這種獨特的氛圍烘托下，你不需要精通 TCP/IP，也無需深諳 Linux 內核原理，哪怕只是一個前端或者網站的 PHP 工程師，都會對如何把自己的代碼打包成一個隨處可以運行的 Docker 鏡像充滿好奇和興趣。
這種受衆羣體的變革，正是 Docker 這樣一個後端開源項目取得巨大成功的關鍵。這也是經典 PaaS 項目想做卻沒有做好的一件事情：PaaS 的最終用戶和受益者，一定是爲這個 PaaS 編寫應用的開發者們，而在 Docker 項目開源之前，PaaS 與開發者之間的關係卻從未如此緊密過。
解決了應用打包這個根本性的問題，同開發者與生俱來的的親密關係，再加上 PaaS 概念已經深入人心的完美契機，成爲 Docker 這個技術上看似平淡無奇的項目一舉走紅的重要原因。
一時之間，“容器化"取代"PaaS 化"成爲了基礎設施領域最炙手可熱的關鍵詞，一個以"容器"爲中心的、全新的雲計算市場，正呼之欲出。而作爲這個生態的一手締造者，此時的 dotCloud 公司突然宣佈將公司名稱改爲"Docker”。
這個舉動，在當時頗受質疑。在大家印象中，Docker 只是一個開源項目的名字。可是現在，這個單詞卻成了 Docker 公司的註冊商標，任何人在商業活動中使用這個單詞，以及鯨魚的 Logo，都會立刻受到法律警告。
Docker 項目在短時間內迅速崛起的三個重要原因：
-
Docker 鏡像通過技術手段解決了 PaaS 的根本性問題；
-
Docker 容器同開發者之間有着與生俱來的密切關係；
-
PaaS 概念已經深入人心的完美契機。
