對于不同的團隊，生產環境意味著不同的東西。在本書中，我們所說的生產環境是指真實客戶用于運行代碼的環境。這是相對于開發環境、預演環境及測試環境而言的，后者的停機時間不會被客戶感知到。 在生產環境中，Docker有時是用于接收公共網絡流量的容器，有時則是用于處理來自隊列負荷的異步的后臺作業。不管哪種用途，在生產環境中運行Docker與在其他環境中運行相比，最主要的差異都是需要在其安全性與穩定性上投入較多的注意力。 編寫本書的動力之一是，與Docker相關的文檔和博客文章中缺乏對實際生產環境與其他環境的明確區分。我們認為，80%的Docker博客文章中的建議在嘗試在生產環境中運行6個月之后會被放棄（或至少修改）。為什么？因為大多數博客文章中舉的都是理想化的例子，使用了最新、最好用的工具，一旦某個極端的情況變成了致命缺陷，這些工具將被遺棄（或延期），被更簡單的方法所取代。這是Docker技術生態系統現狀的一個反映，而非技術博客的缺陷。 總的來說，生產環境很難管理。Docker簡化了從開發到生產的工作流程，但同時增加了安全和編排的復雜度（更多關于編排的內容參見第4章）。 為了節省時間，下面給出本書的重點綜述。 所有在生產環境中運行Docker的團隊，都會在傳統的安全最佳實踐上做出一項或多項妥協。如果無法完全信任容器內運行的代碼，那么就只得選用容器與虛擬機一對一的拓撲方式。對于很多團隊而言，在生產環境中運行Docker的優勢遠遠大于其帶來的安全與編排問題。如果遇到工具方面的問題，請等待一到兩個月，以便Docker社區對其進行修復，不要浪費時間去修補其他人的工具。保持Docker設置最小化。讓一切自動化。最后，對成熟的編排工具（如Mesos、Kubernates等）的需求遠比想象的要少得多。 ### 功能內置與組合工具 Docker社區一個常見的口頭禪是“電池內置但可移除”，指的是將很多功能捆綁在一起的單體二進制文件，這有別于傳統Unix哲學下相對較小、功能單一、管道化的二進制文件。 這種單體式的做法是由兩個主要因素決定的：（1）使Docker易于開箱即用；（2）Golang缺少動態鏈接。Docker及多數相關工具都是用Google的[Go編程語言](https://golang.org/)編寫的，該語言可以簡化高并發代碼的編寫與部署。雖然Go是一門出色的編程語言，但用它來構建的Docker生態系統中也因此遲遲無法實現一個可插拔的架構，在這種架構中可以很容易用替代品對工具進行更換。 如果讀者有Unix系統背景，最好是編譯自己的精簡版Docker守護進程，以符合生產環境的需求。如果讀者有開發背景，預計到2015年下半年，Docker插件將成為現實[\[1\]](#anchor001)。在此期間，估計Docker生態系統中的工具將會出現明顯的重疊現象，某些情況下甚至是相互排斥的。 換句話說，要讓Docker運行于生產環境中，用戶的一半工作將是決定哪些工具對自己的技術棧最有意義。與DevOps所有事情一樣，先從最簡單的解決方案入手，然后在必要時增加其復雜性。 2015年5月，Docker公司發布了[Compose](https://docs.docker.com/compose/)、[Machine](https://docs.docker.com/machine/)及[Swarm](https://docs.docker.com/swarm/)，與Docker生態系統內的同類工具進行競爭。所有這些工具都是可選的，請根據實際情況對其進行評估，而不要認為Docker公司提供的工具就一定是最佳解決方案。 探索Docker生態系統時的另一項關鍵建議是：評估每個開源工具的資金來源及其商業目標。目前，Docker公司和CoreOS經常發布工具，以爭奪關注度和市場份額。一個新工具發布后，最好等上幾個月，看看社區的反應，不要因為它看起來很酷就切換到最新、最好用的工具上。 - - - - - - [[1]](#ac001) Docker 1.7版中正式引入了插件系統。——譯者注