容器5大深坑莫要踩，5種實踐出真知

眾所周知，容器已經在很多互聯網企業以及傳統企業當中實踐應用，這種新興的技術有很多地方會被人誤解，一不小心就會踩到坑，數人云今天分享的文章將討論這些，因為Docker是被最廣泛採用的容器技術，所以以它為例。

Docker的5大誤區

誤區1：Docker是萬靈藥

Docker並不解決雲端所有的問題，所以在容器技術中，需要對計劃目標有合理地規劃，若考慮採用Docker在平台中加一些特定的東西，那麼請自問：目前平台有哪些衍變？若已經有了小的應用服務，可以使用Docker去解決一些問題，但不要試圖讓它解決全部問題。

在評估環境是否合適容器時，經常使用牛或寵物作為比喻，想要遷移到容器，需要的環境是能像對待牲口那樣簡單粗暴，而不是那種嬌滴滴的寵物。若有一個高強度且密集的程序，並且要不斷地為伺服器梳理毛髮（比喻，意思為比較脆弱，需要經常維護），那麼就不適合遷移到容器當中。

如果已經有了一個範圍廣泛且鬆散耦合的集合，就可以很好地運用容器去解決一些，但要是已經有了大量流程模式的挑戰，並且應用管理方法都是非常傳統的，就需要在嘗試遷移之前將這些問題解決掉，在遷移到容器之前，需要致力於不可變的基礎設施概念和實踐。

誤解2：Docker有明確的最佳實踐

如同在其生命周期快速採用階段的任何突破性技術一樣，容器還沒有一組清晰的最佳實踐，本文文末將給出一個較好的實踐，但仍不算最佳。

雖然並沒有什麼「最佳實踐」，但需要知道做什麼，如，早期的想法是不希望在Docker中託管一個資料庫，但現在已經在Docker上運行了整個搜索引擎（又稱龐大的資料庫），並找到了讓它工作的方法。

Docker現在充滿了爭議，但這不意味著要去避開它，而是做到理解前沿的新技術和所做的事情。不要害怕嘗試不同的事務，需要明白它能產生的作用，如果善於思考需要解決的問題，並進行一些實踐測試，可能就會學到很多適合本企業自身的知識，缺乏最佳實踐可能是一種挑戰，但同時也意味著可以不受限地跳出條條框框去思考，想出創造性的辦法去解決老問題。

誤解3：Docker總是比虛擬機便宜

從某個角度去看，運行容器確實會比虛擬機要便宜，比如，有600個AWS實例，分別是1個CPU和4-5GB的RAM，那麼可以使用Docker容器將其減少到100個實例，其中有32個CPU和64G的RAM，因為實例數量的減少就可以顯著地降低成本。

對於一些用例來說這是正確且可行的，至少在短期內如此，但從長遠角度去看，如同其他任何技術一樣，也為應用容器技術花費了不少人力、物力成本，逐漸將其複雜化也帶來了成本上的問題。

當大規模地運行容器時，為了方便管理容器極其資源，不得不投資管理和編排平台，就需要一個全新的技術堆棧，由於沒有明確的最佳實踐，可能會遇到一些反覆出現的錯誤，造成時間和成本上的浪費。

這筆賬不能簡單地去通過對比其價格計算，需要大量的時間去確定優先順序，並理解在運用容器需要的成本是多少。

誤解4：容器可以像虛擬機一樣

容器不僅僅是更小，更離散的虛擬機，而且也是完全獨立的。所以若使用的是像虛擬機那樣的容器，護著打算再Docker容器中構建虛擬機，那麼還是建議就此罷手，因為可能會導致一些重大問題。

將Docker想像成一台3D印表機，輸入需求→Poof→出現容器，現在這是一個整體和自包含對象而並非是可以編輯或刪除的對象。如果某些項不正確或需要新項，不得不進行重複性工作。

當運用Docker容器時需要自問一下如：

• 集成應用真正的含義是什麼
• 是否了解依賴關係

如果能自答出這些問題，並構建適合容器的新工作流程，那麼就能很便捷地實現。

誤解5：Docker與虛擬機具有相同的安全模型

很多人部署了Docker後，認為它具有與虛擬機相同的安全模型，但可惜地是並非如此，Docker雖與操作系統有關，但它並不是操作系統，很多人使用名為Core OS的縮放操作系統運行容器，除了運行Docker，其無法做更多的事情。應用通常仍然需要更傳統的操作系統提供一些東西，例如，從一個Linux發行版（如Ubuntu）構建容器。

一整套的安全挑戰出現在遷移到容器時。其中一些是因為「一個進程一個容器」的最初目標難以執行，所以人們找到了實際上容器一個非常重要的特徵捷徑和方法。

若闖入容器化的環境，當發生的事件導致安全問題時，需要建立告警，比如構建了一系列容器運行的Java應用，若除了Java之外任何操作都開始運行就應該告警。

值得注意的是，容器可以讓人真正了解這些類型的告警，可以縮小查找內容，但編寫這些規則應用它們以及隨著時間推移去進行管理則是一項挑戰。

Docker的5大實踐

前文說過，Docker目前並沒有什麼「最佳實踐」，但本文仍會給出5個實踐來供以參考：

實踐1：基於應用的日誌記錄

在基於應用的方法中，容器內的應用使用日誌框架來處理日誌記錄過程，如一個Java應用可能會用Log4j 2去格式化和發送日誌文件到遠程伺服器，並完成繞過Docker和操作系統。

雖然基於應用的日誌記錄使開發這對日誌事件有了最大控制，但這種方法也會在應用過程中產生大量開銷，對於哪些在更傳統的應用環境工作的人來說可能是有用的，因為其允許開發者繼續使用應用的日誌框架，無需向主機添加日誌功能。

Docker實際上意味著不僅記錄應用和主機操作系統，還包括Docker服務。

實踐2：使用數據卷

容器本質上是臨時的，因此若掛掉，裡面任何文件都會丟失，相反，容器必須將日誌事件轉發到集中式日誌記錄服務（比如日誌記錄），或將日誌事件存儲在一個數據卷中（被定義為容器內的一個標記目錄，該目錄存在保存持久或共享的數據）。

使用數據卷記錄事件的好處有：由於它們鏈接到主機上的一個目錄，所以日誌數據仍然存在，並且可以與其他容器共享，減少了容器關閉時丟失數據的可能性。（參見：https://www.digitalocean.com/community/tutorials/how-to-work-with-docker-data-volumes-on-ubuntu-14-04）

實踐3：Docker日誌驅動程序

在Docker中記錄實踐的方式是使用平台的日誌記錄驅動程序將日誌事件轉發到在主機上運行的Syslog實例。Docker日誌驅動程序直接從容器的Stdout和Stderr輸出入去日誌事件，這消除了從日誌文件讀取和寫入的需要，轉化為性能增益。 但使用Docker日誌驅動程序有一些缺點：

不允許日誌解析，只能記錄轉發

Docker日誌命令僅適用於日誌驅動程序JSON文件

當TCP伺服器無法訪問時，容器終止。

（參見：https://www.digitalocean.com/community/tutorials/how-to-work-with-docker-data-volumes-on-ubuntu-14-04）

實踐4：專用記錄容器

此種方法的主要優點在於可在Docker環境中完全管理日誌事件。由於專用日誌記錄容器能從其他容器收集日誌事件，聚合它們，然後將事件存儲或轉發到第三方服務，因此此方法消除了對主機的依賴，附加優點有：

自動收集，監控和分析日誌事件

自動縮放日誌事件，無需配置

通過多個日誌事件，統計信息和Docker API數據流檢索日誌。

實踐5：側面方法

Sidecar已成為管理微服務架構的流行方式，側面的想法來源於摩托車側車架如何附著在摩托車上的類比，有消息稱：一個Sidecar作為第二個進程與服務一起運行，並提供了通過同類界面暴露的平台基礎設施功能，例如通過HTTP的類似REST的API。從日誌角度看，優點是每個容器都鏈接到自己的日誌記錄容器（應用容器保存日誌事件和記錄容器標籤，並將其轉發到Loggly的日誌記錄管理系統）。

總結

不得不說，Docker容器是一項非常具有潛力而且十分炫酷的新技術，實踐出真知，去了解Docker如何適應應用自身整體的策略非常值得，當了解了容器這些深坑之後，就可以避開它，同時也多去技術社區和線下交流了解更多的方法模式，不斷充實自身。

原文作者：Megan Rees Ahigian 原文鏈接：https://dzone.com/articles/5-common-myths-around-moving-to-docker?utm_source=tuicool&utm_medium=referral