對容器中應用程序的配置和日志的認知

近日在遷移應用到Docker的過程中，糾結于配置和日志處理，通過查閱網友們的對此的討論、官方鏡像的處理手法，結合實踐，對此有所認知，歡迎斧正。以下內容，均是基于測試/生產環境，不涉及開發環境。

關于配置

通過幾個開源項目（Wordpress，MySQL）的官方鏡像處理方式，來窺探一下關于配置參數的處理手法。

• 通過“環境”傳遞配置參數到容器。
• 容器內通過ENTRYPOINT指令配置的腳本接收環境變量，并按格式寫入配置文件。
• ENTRYPOINT腳本通過exec指令啟動CMD指令。

觀點

• “環境”是傳遞數據到容器內應用程序的常規手法，但數據項太多時，會給維護造成困擾。
• 通過“ENTRYPOINT”指令配置的腳本，完成配置的初始化是一個合理的選擇。
• 配 置初始化。實踐中，配置項往往規模較大，被集中管理(zookeeper/etcd)，需要區分部署的環境（測試/生產）。在此場景下，將“部署環境標 識”通過“環境變量”傳遞到容器，在容器啟動時，通過entrypoint腳本根據“環境標識”和“應用程序配置項需求”（應用程序一般會有關于配置的 schema文件，描述了需要哪些配置項），從配置管理設施中獲取配置數據，完成配置的初始化后，啟動應用程序。
• 配置項變更。配置項的變更一般涉及兩項：如何捕獲這些更新（watch配置管理設施，由誰來watch?），以及如何讓新配置生效（一般意味著進程輪換，如nginx；或者php項目中清理apc緩存）。在 Docker場景下，應當使用能與編排工具通信的設施負責捕獲變更，并將變更轉換為與鏡像相關，提交給編排工具，由編排工具啟動新容器輪換掉老容器，完成 配置生效。 那些企圖在容器內部捕獲配置變更，然后使配置生效的處理手法，不符合Docker的設計精神，而且往往復雜度高。

關于日志

《使用 Fluentd 管理 Docker 日志》一文對Docker日志的討論，受益匪淺。

觀點：

• 從當前實際來看，通過掛載volume到容器，應用程序將日志寫入volume，然后通過宿主機上的agent實現收集，更具可操作性，與主機模型的日志處理幾乎一致。當然，正如作者所言，這需要應用程序將日志寫入volume。如果我們將日志視作業務數據，將Volume作為存儲的話，那這也合乎情理。

對于web服務器來說，訪問日志是其生產的內容，對于日志分析系統來說，訪問日志就是業務數據。

• Docker收集容器內應用程序的stdout、stderr，并存儲為日志，只是一種實現。但它并不是（至少現在不是）為大規模日志（如web服務器）而設計，如果這種機制不滿足需求，我們就需要辯證的使用它。
• 如 果仍堅持使用Docker的日志機制（通過stdout，stderr收集應用程序日志），在制定rotate機制時，可考慮容器的生命周期，或許以日志 的輪轉周期，啟動新容器替換舊容器更符合docker場景。但這對于會產生大量日志的應用來說，也會帶來問題：以什么樣的頻率輪換?
• 如果使用Docker的日志機制，在收集時可考慮動態的方案。以Flume機制為例：主機上監聽Docker事件，以容器label區分業務類型，當監聽到start事件時，動態生成配置文件，并啟動agent。日志數據通過docker logs -f 容器ID獲取。當監聽到stop事件，在日志采集完后，清理掉agent及相關配置。這里有幾個問題：由于日志采集是異步的，如何認定日志已經采集完？另外編排系統在何時刪除掉被停止的容器，當容器停止被刪除后，該容器的所有數據會被清理，如何協調它們？這引入了復雜度。

小結

容器的啟用和銷毀的成本低，在生命周期管理上，往往通過容器的輪換來處理一些原來需要精細化控制的細節，如果照搬主機的處理模式，會很難受，且格格不入。

參閱

• 一種Docker化應用程序的簡單方法
• 使用 Fluentd 管理 Docker 日志
• 容器里Nginx、MySQL的配置文件、日志是否應該掛載到宿主機上
• 請教下代碼放在Docker里面還是外面呢

來自：http://dockone.io/article/637