所有的服務都開始了容器化升級，在一切皆容器的主流思想下，無狀態的服務采用容器化已經是大勢所趨，常常困擾架構師的一個問題是，數據庫是否需要容器化？
數據庫不適合容器化的七大原因
1. 數據不安全
即使你要把 Docker 數據放在主機來存儲 ，它依然不能保證不丟數據。 Docker volumes 的設計圍繞 Union FS 鏡像層提供持久存儲，但它仍然缺乏保證。
使用當前的存儲驅動程序，Docker 仍然存在不可靠的風險。 如果容器崩潰並數據庫未正確關閉，則可能會損壞數據。
2. 運行數據庫的環境需求
常看到 DBMS 容器和其他服務運行在同一主機上。 然而這些服務對硬件要求是非常不同的
數據庫（特別是關系型數據庫）對 IO 的要求較高。 一般數據庫引擎為了避免並發資源競爭而使用專用環境。如果將你的數據庫放在容器中，那么將浪
費你的項目的資源。 因為你需要為該實例配置大量額外的資源。 在公有雲，當你需要 34G 內存時，你啟動的實例卻必須開 64G 內存。在實踐中，這些
資源並未完全使用。
怎么解決？ 您可以分層設計，並使用固定資源來啟動不同層次的多個實例。 水平伸縮總是比垂直伸縮更好。
3. 網絡問題
要理解 Docker 網絡，您必須對網絡虛擬化有深入的了解。也必須准備應付好意外情況。你可能需要在沒有支持或沒有額外工具的情況下，進行 bug 修復。
我們知道：數據庫需要專用的和持久的吞吐量，以實現更高的負載。我們還知道容器是虛擬機管理程序和主機虛擬機背后的一個隔離層。然而網絡對於
數據庫復制是至關重要的，其中需要主從數據庫間 24/7 的穩定連接。未解決的 Docker 網絡問題在1.9版本依然沒有得到解決。
把這些問題放在一起，容器化使數據庫容器很難管理。我知道你是一個頂級的工程師，什么問題都可以得到解決。但是，你需要花多少時間解決 Docker
網絡問題？將數據庫放在專用環境不會更好嗎？節省時間來專注於真正重要的業務目標。
4.狀態
在 Docker 中打包無狀態服務是很酷的，可以實現編排容器並解決單點故障問題。 但是數據庫呢？ 將數據庫放在同一個環境中，它將會是有狀態的，並
使系統故障的范圍更大。下次您的應用程序實例或應用程序崩潰，可能會影響數據庫。
5.數據庫不適合使用主要的docker功能
考慮容器中的數據庫，我們來思考它的價值。 我們先看看 Docker 官方對其的定義：
Docker 是為開發人員和系統管理員構建，分發和運行分布式應用程序的開放平台。 Docker 包括 Docker Engine（便攜式，輕量級運行時和打包工具）
以及 Docker Hub（用於共享應用程序和自動化工作流的雲服務），Docker 使應用程序能夠以組件快速組裝，並消除開發，QA 和生產環境之間的不
同。 因此，IT 可以更快地分發程序，並在筆記本電腦，數據中心虛擬機和任何雲上運行相同的應用程序。
根據該答案，我們可以很容易定義 Docke r的主要特性：
-
-
- 易於構建新環境
- 易於重新部署（持續集成）
- 容易水平伸縮（從實踐得出）
- 易於維護環境一致
-
讓我們開始思考這些功能如何適應數據庫世界。
容易設置數據庫？ 讓我們看看，容器化或者在本地運行數據庫，在運行上是否有巨大的差異。
docker run -d mongod:3.4
對比：
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6 echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list sudo apt-get update && sudo apt-get install -y mongodb-org
易於構建新環境？如果我們談論是 MongoDB集群 - 可能容器化效率更高。但是配置管理系統呢？它們旨在通過運行一個命令來解決配置問題。使用
Ansible 你可以輕松設置幾十個 Mongo 實例。正如你所看到的，沒有顯著的價值增長。
容易重新部署？您重新部署數據庫升級到下一個版本的頻率是多少呢？數據庫升級不是可用性問題，而是工程問題（即在群集中的可用性）。想想你的
應用程序將如何使用新的數據庫引擎版本。引擎更換時可能導致的問題。
容易水平伸縮？是否要在多個實例之間共享數據目錄？你不害怕直接數據並發問題和可能的數據損壞嗎？使用專用數據環境部署多個實例不會更安全
嗎？最后搞一個主從復制？
易於維護環境一致？數據庫實例環境的變化頻率如何？每天升級操作系統嗎？還是數據庫版本或依賴軟件變化頻繁？或者是不容易與工程團隊達成共
識？
最后看來，沒有一個特性足以讓我考慮數據庫容器化。
6. 額外的隔離對數據庫是不利的
其實我在第二點和第三點原因中提到了這一點。 但我把這個列為單獨的原因，因為我想再次強調這一事實。 我們擁有的隔離級別越多，我們獲得的資源
開銷就越多。 相比專用環境而言，容易水平伸縮可以使我們得到更多的好處。 然而在 Docker 中水平伸縮只能用於無狀態計算服務，而不是數據庫。
我們沒有看到任何針對數據庫的隔離功能，那為什么我們應該把它放在容器中？
7.雲平台的不適用性
大部分人通過共有雲開始項目。 雲簡化了虛擬機操作和替換的復雜性，因此不需要在夜間或周末沒有人工作時間來測試新的硬件環境。當我們可以迅速
啟動一個實例的時候，為什么我們需要擔心這個實例運行的環境？
這就是為什么我們向雲提供商支付很多費用的原因。 當我們為實例放置數據庫容器時，上面說的這些便利性就不存在了。因為數據不匹配，新實例不會
與現有的實例兼容，如果要限制實例使用單機服務，應該讓 DB 使用非容器化環境，我們僅僅需要為計算服務層保留彈性擴展的能力。
這 7 點適用於所有數據庫嗎？
也許不是全部，但是應該是一切需要持久化數據的數據庫，以及所有具有特殊硬件環境要求的數據庫。
如果我們使用 Redis 作為緩存或用戶會話存儲- 使用容器就不應該有任何問題。因為不需要保證該數據落地，那么數據沒有丟失的風險。但是如果我們
考慮使用 Redis 作為一個持久的數據存儲，那么你最好把數據放在容器外面，即使您不斷刷新 RDB 快照，在快速變化的計算集群中找到這個快照也會
很復雜。
我們還可以談談容器內的 Elasticsearch。我們可以存儲在 ES 中的索引，並且可以從持久性數據源重建它們。但是看看要求！默認情況下，
Elasticsearch 需要 2 到 3GB 的內存。由於 Java 的 GC，內存使用並不一致。您確定Elasticsearch 適合用於資源限制的容器嗎？讓不同的
Elasticsearch 實例使用不同的硬件配置不是更好嗎？
不要擔心本地開發環境的數據庫容器化。將數據庫放在本地環境的容器中，你將節省大量的時間和精力。你將能夠復制生產環境操作系統。原生
Postgres for OS X或Windows不是100％兼容Linux版本。在主機操作系統上設置容器而不是軟件包，你會克服這種問題。