Docker所使用的底層容器技術已經存在了很多年，甚至早于[dotCloud](https://www.dotcloud.com/)這家平臺即服務（PaaS）創業公司，即后來我們所熟知的Docker。在dotCloud之前，許多知名的公司（如[Heroku](https://www.heroku.com/)和[Iron.io](http://www.iron.io/)）已經在生產環境中運行大型容器集群，以獲取額外的超越虛擬機的性能優勢。與虛擬機相比，在容器中運行軟件賦予了這些公司秒級而非分鐘級的實例啟動與停止的能力，同時能使用更少的機器運行更多實例。 既然這項技術并不新鮮，為什么Docker能獲得如此巨大的成功呢？主要是因為它的易用性。Docker創造了一種統一的方式，通過簡便的命令行及HTTP API工具來打包、運行和維護容器。這種簡化降低了將應用程序及其運行時環境打包成一個自包含鏡像的入門門檻，使之變得可行且有趣，而不需要類似Chef、Puppet及Capistrano之類的配置管理和發布系統。 Docker提供了一種統一手段，將應用程序及其運行時環境打包到一個簡單的Dockerfile里，這從根本上改變了開發人員與DevOps團隊之間的交互界面。從而極大簡化了開發團隊與DevOps之間的溝通需求與責任邊界。 在Docker出現之前，各個公司的開發與運維團隊之間經常會爆發史詩般的戰爭。開發團隊想要快速前進，整合最新版的軟件及依賴，以及持續部署。運維團隊則以保證穩定為己任，他們負責把關可以運行于生產環境中的內容。如果運維團隊對新的依賴或需求感到不適，他們通常會站在保守的立場上，要求開發人員使用舊版軟件以確保糟糕的代碼不會搞垮整臺服務器。 Docker一下子改變了DevOps的決策思維，從“基本上說不”變成了“好的，只要運行在Docker中就可以”，因為糟糕的代碼只會讓容器崩潰，而不會影響到同一服務器上的其他服務。在這種泛型中，DevOps有效地負責為開發人員提供PaaS，而開發人員負責保證其代碼能正常運行。如今，很多團隊將開發人員加入到PagerDuty中，以監控他們在生產環境中的代碼，讓DevOps和運維人員專注于平臺的穩定運行及安全。 ### 開發環境與生產環境 對大多數團隊而言，采用Docker是受開發人員更快的迭代和發布周期需求推動的。這對于開發環境是非常有益的，但對于生產環境，在單臺宿主機上運行多個Docker容器可能會導致安全漏洞，這一點我們將在第6章“安全”中講述。事實上，幾乎所有關于在生產環境中運行Docker的話題都是圍繞著將開發環境與生產環境區分開的兩個關注點進行的：一是編排，二是安全。 有些團隊試圖讓開發環境和生產環境盡可能保持一致。這種方法看起來很好，但是限于開發環境這樣做所需定制工具的數量又或者說模擬云服務（如AWS）的復雜度，這種方法并不實際。 為了簡化這本書的范疇，我們將介紹一些部署代碼的用例，但判定最佳開發環境設置的實踐機會將留給讀者。作為基本原則之一，盡量保持生產環境和開發環境的相似性，并使用一個持續集成/持續交付（CI/CD）系統以獲取最佳結果。