很多人最終還是決定使用 Docker 解決問題。 Docker 的優點很多，比如：

• 一體化——將操作系統、庫版本、配置文件、應用程序等全部打包裝在容器里。從而保證 QA 所測試的鏡像 (image) 會攜帶同樣的行為到達生產環境。
• 輕量——內存占用極小，只為主要過程分配內存。
• 快讀——一鍵啟動，就像啟動常見的 linux 過程一樣快。

盡管如此，眾多用戶仍然只是把容器當做常見的虛擬機，而忘記了容器的一個重要特性：

用后即棄

正因為這一特點，一些用戶需要改變他們對容器的觀念，為了更好的使用與發揮 Docker 容器的價值，有一些事情是絕對不應該做的： 

1.不要在容器（container）中存儲數據 容器可能會被中斷、被替換或遭到破壞。在容器中運行的 1.0 版應用程序很容易就會被 1.1 版取代，而不會對數據造成影響或導致數據丟失。因此，如果需要存儲數據，請存儲在卷 (volume) 中。在這一情況下，還應注意兩個容器是否會在同一個卷上寫入數據，這將導致損壞。請確保應用程序適用于寫入共享的數據存儲。

2. 不要分兩部分傳送應用程序 有些人把容器當作虛擬機，所以他們大多會認為，應該將應用程序部署到現有正在運行的容器中。在需要不斷部署和調試的開發階段，可能確實如此；但對于 QA 和生產的持續交付 (CD) 渠道，應用程序應當是鏡像的一部分。切記：容器轉瞬即逝。

3. 不要創建大尺寸鏡像 大尺寸的鏡像難以分配。請確保僅使用必需文件和庫來運行應用程序。不要安裝不必要的數據包，也不要運行“更新”(yum update)，這些操作會把大量文件下載到新的鏡像層。

4. 不要使用單層鏡像 為了有效利用多層文件系統，請始終為操作系統創建屬于自己的基本鏡像層，然后為用戶名定義創建一個層，為運行時安裝創建一個層，為配置創建一個層，最后再為應用程序創建一個層。這樣，重新創建、管理和分配鏡像就會容易些。

5. 不要從正在運行的容器中創建鏡像 換句話說，不要使用"docker commit"命令來創建鏡像。這一鏡像創建方法不可復制，因此應完全避免使用。請始終使用 Dockerfile 或其他任何可完全復制的 S21（從源代碼到鏡像）方法，如此一來，如果存儲在源代碼控制存儲庫 (GIT) 中，就可以跟蹤 Dockerfile 的變更情況。

6. 不要只使用“最新版”標簽 最新版標簽就像 Maven 用戶的“快照”(SNAPSHOT) 一樣。容器具有多層文件系統這一基本特征，所以我們鼓勵使用標簽。相信誰也不愿意在構建了幾個月的鏡像后，突然發現應用程序因為父層（即 Dockerfile 中的 FROM）被新版本取代而無法運行（新版本無法向后兼容或從構建緩存中檢索的“最新“版有誤）這樣的意外吧？在生產過程中部署容器時也應避免使用”最新版“標簽，這是因為無法跟蹤當前運行的鏡像版本。

7. 不要在單個容器中運行一個以上進程 容器只運行一個進程（HTTP 守護進程、應用程序服務器、數據庫）時效果最佳，但如果運行一個以上進程，在管理和檢索日志以及單獨更新進程時就會遇到很多麻煩。

8. 不要在鏡像中存儲證書及使用環境變量。 不要在鏡像中對任何用戶名/密碼進行硬編碼操作。請使用環境變量從容器外部檢索信息。Postgres 鏡像就是這一原理的極佳詮釋。

9. 不要以 root 權限運行進程 “默認情況下，Docker 容器以 root 用戶權限運行。（……）隨著 Docker 技術日趨成熟，能夠使用的安全默認選項越來越多。目前，要求 root 對其他用戶來說較為危險，另外，不是所有環境都能夠使用 root。鏡像應使用 USER 指令來為容器的運行指定非 root 用戶。”（摘自《Docker 鏡像作者指南》(Guidance for Docker Image Authors)）

10. 不要依賴 IP 地址 每個容器都有自己的內部 IP 地址，如果啟動然后停止容器，內部 IP 地址可能會發生變化。如果你的應用程序或微服務需要和另一個容器進行通信，請使用環境變量在容器之間傳遞相應的主機名和端口。

11. 監控容器 Docker 監控已經越來越受到開發者們的重視，實時監控 Docker 的方法，這里推薦 Cloudinsight。 不同于一些需要自寫腳本的監控手段，Cloudinsight 作為一家免費的 SaaS 服務，能夠一鍵監控 Docker，且擁有很棒的可視化界面。除此之外，Cloudinsight 還支持多種操作系統、數據庫等的監控，能夠一體化展示所有被監控的系統基礎組件的性能數據。