當你最後投入容器的懷抱，發現它能解決很多問題，而且還具有眾多的優點:

1. 第一：它是不可變的 – 作業系統，庫版本，配置，資料夾和應用都是一樣的。您可以使用通過相同QA測試的映象，使產品具有相同的表現。

2. 第二：它是輕量級的 – 容器的記憶體佔用非常小。不需要幾百幾千MB，它只要對主程序分配記憶體再加上幾十MB。

3. 第三：它很快速 – 啟動一個容器與啟動一個單程序一樣快。不需要幾分鐘，您可以在幾秒鐘內啟動一個全新的容器。

但是，許多使用者依然像對待典型的虛擬機器那樣對待容器。但是他們都忘記了除了與虛擬機器相似的部分，容器還有一個很大的優點：它是一次性的。容器的準則 ：“容器是臨時的”。

容器是臨時的

這個特性“本身”促使使用者改變他們關於使用和管理容器的習慣；我將會向您解釋在容器中不應該做這些事，以確保最大地發揮容器的作用。

1) 不要在容器中儲存資料 –  容器可能被停止，銷燬，或替換。一個執行在容器中的程式版本1.0，應該很容易被1.1的版本替換且不影響或損失資料。有鑑於此，如果你需要儲存資料，請存在卷中，並且注意如果兩個容器在同一個捲上寫資料會導致崩潰。確保你的應用被設計成在共享資料儲存上寫入。

2) 不要將你的應用釋出兩份 –  一些人將容器視為虛擬機器。他們中的大多數傾向於認為他們應該在現有的執行容器裡釋出自己的應用。在開發階段這樣是對的，此時你需要不斷地部署與除錯；但對於質量保證與生產中的一個連續部署的管道，你的應用本該成為映象的一部分。記住：容器應該保持不變

3) 不要建立超大映象 – 一個超大映象只會難以分發。確保你僅有執行你應用/程序的必需的檔案和庫。不要安裝不必要的包或在建立中執行更新（yum更新）。

4) 不要使用單層映象 – 要對分層檔案系統有更合理的使用，始終為你的作業系統建立你自己的基礎映象層，另外一層為安全和使用者定義，一層為庫的安裝，一層為配置，最後一層為應用。這將易於重建和管理一個映象，也易於分發。

5) 不要為執行中的容器建立映象 – 換言之，不要使用“docker commit”命令來建立映象。這種建立映象的方法是不可重現的也不能版本化，應該徹底避免。始終使用Dockerfile或任何其他的可完全重現的S2I（源至映象）方法。

6) 不要只使用“最新”標籤 – 最新標籤就像Maven使用者的“快照”。標籤是被鼓勵使用的，尤其是當你有一個分層的檔案系統。你總不希望當你2個月之後建立映象時，驚訝地發現你的應用無法執行，因為最頂的分層被非向後相容的新版本替換，或者建立快取中有一個錯誤的“最新”版本。在生產中部署容器時應避免使用最新。

7) 不要在單一容器中執行超過一個程序 – 容器能完美地執行單個程序（http守護程序，應用伺服器，資料庫），但是如果你不止有一個程序，管理、獲取日誌、獨立更新都會遇到麻煩。

8) 不要在映象中儲存憑據。使用環境變數 –不要將映象中的任何使用者名稱/密碼寫死。使用環境變數來從容器外部獲取此資訊。有一個不錯的例子是postgres映象。

9) 使用非root使用者執行程序 – “docker容器預設以root執行。（…）隨著docker的成熟，更多的安全預設選項變得可用。現如今，請求root對於其他人是危險的，可能無法在所有環境中可用。你的映象應該使用USER指令來指令容器的一個非root使用者來執行。”（來自Docker映象作者指南）

10) 不要依賴IP地址 – 每個容器都有自己的內部IP地址，如果你啟動並停止它地址可能會變化。如果你的應用或微服務需要與其他容器通訊，使用任何命名與（或者）環境變數來從一個容器傳遞合適資訊到另一個。