Docker是一個開源的應用容器引擎,在虛擬的容器環境之上增加一個應用部署引擎。它是一個輕量級但十分強大的關於虛擬化技術的開源容器，在容器中還整合了構建並容器化應用的工作流程。目前大家已經開始認同並接受容器技術，並意識到它能夠解決多種現實問題並具備一系列無可比擬的優勢。今天就和大家聊一聊容器技術的優勢和誤區，幫助大家更好地理解和使用Docker。

Docker容器的三大優勢：

1. 第一：具備恆定特性–作業系統、庫版本、配置、資料夾以及應用程式全部涵蓋在內。大家可以將質量檢查流程中使用的測試映象原封不動地引入生產環境當中。
2. 第二：具備輕量化特性–容器的體積非常小巧。相較於動輒成百上千MB的作業系統，它只需要配備主程序所必需的記憶體外加數十MB額外容量。
3. 第三：速度驚人–大家可以享受等同於單一程序的容器啟動速度。相較於長達數分鐘的傳統負載啟動時長，現在我們完全能夠在幾秒鐘內啟動一套新容器。 
   不過很多使用者仍然在以對待典型虛擬機器的方式審視容器，在這種情況下他們往往沒辦法發揮容器技術所蘊含的各類優勢。因此我們需要再次強調一項基本原則：容器具備一次性特徵。

容器座右銘： “容器屬於臨時性（一次性）系統。”

這一特性的存在要求使用者轉變既有思路，選擇更為合適的方針處理並管理容器。接下來，我會通過十種常見誤區幫助大家瞭解發揮容器優勢的合理途徑：

1)不要將資料存放在容器內——容器系統可隨時進行停止、銷燬或者替換。執行在容器環境下的應用程式1.0版本應該可以輕鬆更換為1.1版本，且不會影響或者破壞相關資料。考慮到這一點，如果大家需要儲存資料，請將其儲存在儲存卷當中；不過需要注意的是，如果有兩套容器同時指向同一儲存卷，則可能引發故障。大家必須確保自己的應用程式使用面向共享式資料儲存機制寫入設計方案。

2)不要以拆分方式進行應用程式釋出——有些朋友仍然帶著虛擬機器思路審視容器。他們大多認為自己應該將應用程式部署至當前正在執行的容器當中。然而，這種作法只適用於開發階段，從而實現應用開發所必需的持續部署與除錯；一旦轉移至質量檢查與生產環境下的持續部署流程，應用程式則必須作為映象本身的組成部分。請記住：容器具有恆定特性。

3)不要建立大型映象——體積過大的映象會加大其釋出難度。大家需要確保在映象中只保留執行應用程式/程序所必需的檔案與庫。不要安裝任何非必要軟體包或者在構建過程中執行“更新”（yum update）。

4)不要使用單層映象——為了更合理地使用分層檔案系統，請大家務必為作業系統、安裝軟體、配置以及應用程式分別建立獨立層。這不僅能夠簡化映象的建立與管理工作，亦能降低分發難度。

5) 不要利用執行中的容器建立映象——換言之，不要使用“docker commit”建立映象。以這種方式建立的映象不具備再生產能力且無法實現版本控制性，因此絕對不值得提倡。相反，使用Dockerfile或者任何S2I（即源到映象）方法能夠有效確保整體再生產能力。

6)不要只使用“最新”標籤——最新標籤類似於Maven使用者所熟悉的“SNAPSHOT”。各標籤只適合在分層檔案系統當中使用。如果大家在映象構建完成的兩個月之後，意外發現自己的應用程式由於頂層版本替換而造成向下相容性缺失或者build快取“最新”版本無法執行，那麼無疑會造成巨大的麻煩。總體來講，在向生產環境中部署容器時，必須避免使用最新標籤。

7)不要在單一容器內執行多個程序——容器系統非常適合執行單一程序（例如http域名、應用程式伺服器以及資料庫等等），但如果大家在容器內使用多個程序，則可能很難對其分別進行管理、獲取日誌記錄以及更新。

8)不要在映象內儲存憑證，建議使用環境變數——大家絕對不要以硬編碼形式在映象中儲存任何使用者名稱/密碼。相反，我們應當利用環境變數從容器之外獲取此類資訊。在這方面，最完美的示例就是postgres映象。

9)以非root使用者執行程序——“預設情況下，Docker容器以root方式執行。隨著Docker的不斷髮展成熟，更多更為安全的預設選項亦陸續出現。就目前而言，使用root許可權仍有可能造成安全隱患且缺乏對全部環境的良好適應效果。大家的映象應當使用USER指令將容器指定為非root使用者角色”。（來自Docker映象建立者指南）

10)不要依賴於IP地址——每套容器都擁有自己的內部IP地址，而容器的每次啟動與停止都有可能導致IP地址發生改變。如果應用程式或者微服務需要與其它容器通訊，那麼請使用能夠將相關資訊由此容器傳遞至彼容器的名稱與/或環境變數。

Docker技術作為當前最火爆的技術，仍在一個落地和普及的過程中。大家在使用過程中應當拋開傳統的觀念和想法，避免走入誤區、繞進彎路，在技術轉型的過程中先人一步。