Docker高手十一法則

不少人最終仍是決定使用 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 還支持多種操做系統、數據庫等的監控，可以一體化展現全部被監控的系統基礎組件的性能數據。

遵照這十一條，你就是 Docker 高手了！