將數據庫作為Docker容器或裸機服務器運行？

Question

數據庫旨在消耗它們可用的所有內存，CPU和IO。 有沒有好/壞的原因Docker不應該用於生產中的數據庫？

可能這個問題適用於其他工具，如MOM Apache Kafka，Apache ActiveMQ等。

Answer 1

Docker不是一個完整的虛擬機（至少在Linux上運行時），這只是在同一個內核上運行的另一個進程，也就是主機。 此外，所有docker容器進程都可以在具有ps aux的主機中看到。

Docker提供的唯一額外負載是在內核之上加載另一個操作系統，但實際上大多數容器都部署了非常輕量級的東西，如alpine Linux，所以我不認為它真的必須考慮。

從另一點來看，在容器中擁有數據庫（或任何其他高負載服務）具有以下優勢：

• 擴展（容器可以通過容器編排工具（如k8s ）輕松地在節點之間傳播）
• 易於部署（所有依賴項都在內部）
• 輕松升級（只需更換容器）
• 易於測試（在運行測試之前無需數據庫清理程序）和其他

因此，今天部署集裝箱化服務是一種正確的做法。

Answer 2

容器旨在通過使用cgroup來管理資源使用，因此只要我們能夠預測使用情況，我們應該沒有問題（有性能）在容器中運行它。 但是，除了資源使用之外還有其他考慮因素。

在像Kubernetes這樣的架構中，管理數據庫部署變得更加復雜，部分原因是容器現在是短暫的。 如果某個pod在給定節點上出現故障，則無法保證它將在同一節點上恢復，因此需要對有狀態應用程序進行特殊考慮（必須在重新啟動時將pod掛載到同一卷上等） 。 這是同樣的結構StatefulSets進來。所以，它的工作原理，以及解決方案， 非常深思熟慮的，但也有一些更具操作性的跳火圈通過。

還有像Operators這樣的東西可以處理啟動和管理有狀態應用程序（如數據庫或分布式消息隊列）的復雜需求。 這些項目有時可能非常綠色 ，但是有很多行為很難在裸機上精心安排我們開箱即用。

或多或少，在一天結束時，在Kubernetes（或其他容器協調器）上運行有狀態的應用程序（如數據庫或消息隊列）是一個有爭議的話題。 與所有設計決策一樣，存在彈性，復雜性和可調試性的權衡。 很多大公司都在生產這樣做，所以這絕不是不合理的。