作为Docker容器还是在裸机服务器上运行数据库？

Question

数据库被设计为消耗所有可用的内存，CPU和IO。 是否有好/坏原因不应该将Docker用于生产中的数据库？

这个问题可能适用于其他工具，例如MOM，Apache Kafka，Apache ActiveMQ等。

Answer 1

Docker不是一个完整的虚拟机（至少在Linux上运行时），这只是另一个进程，与主机在同一内核上运行。此外，所有docker容器进程都可以在带有ps aux的主机中看到。

Docker唯一的额外负载就是在内核之上加载另一个OS，但是实际上大多数容器都部署有alpine Linux之类的轻量级东西，因此我认为它不一定是考虑在内。

从另一方面讲，在容器中包含数据库（或任何其他高负载服务）可以为您带来以下好处：

• 扩展（使用k8s之类的容器编排工具，容器可以轻松地分布在节点之间）
• 易于部署（所有依赖项都在内部）
• 轻松升级（只需更换容器）
• 易于测试（无需在运行测试之前进行数据库清理程序） 和其他人

因此，今天部署容器化服务是正确的做法。

Answer 2

容器的设计旨在通过使用cgroups来规范资源使用，因此，只要我们能够预测使用情况，就不会在容器中运行它（性能）。但是，除了资源使用之外，还有其他注意事项。

在像Kubernetes这样的体系结构中，管理数据库部署变得更加复杂，部分原因是容器现在是短暂的。如果Pod在给定节点上发生故障，则无法保证它将在同一节点上恢复，因此对于有状态应用程序，需要特别注意（在重新启动Pod时必须将Pod安装到相同的卷上，等等）。 。这就是StatefulSets之类的构造出现的地方。因此，它可以正常工作，并且解决方案和非常都经过深思熟虑，但是还有更多的操作难关。

诸如Operators之类的东西也可以处理启动和管理有状态应用程序（如数据库或分布式消息队列）的复杂需求。这些项目可以是quite green at times，但是很多行为很难协调我们直接使用的裸机。

最终，或多或少地，在Kubernetes（或其他容器协调器）上运行数据库或消息队列之类的有状态应用程序是一个有争议的话题。像所有设计决策一样，要在弹性，复杂性和可调试性之间进行权衡。许多大公司正在生产中进行此操作，因此这绝不是不合理的。