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

Question

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

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

Answer 1

Docker 不是一个完整的虚拟机（至少在 Linux 上运行时），这只是另一个进程，运行在与主机相同的内核上。此外，所有

docker

容器进程都可以在具有

ps aux

的主机中看到。

Docker

提供的唯一额外负载是在内核之上加载另一个操作系统，但实际上大多数容器都部署了像

alpine

Linux这样的极其轻量级的东西，所以我认为实际上不必考虑它。

从另一个角度来看，在容器中拥有数据库（或任何其他高负载服务）可以为您带来以下优势：

• 扩展（使用

  k8s

  等容器编排工具可以轻松地将容器分布在节点之间）
• 轻松部署（所有依赖项都在里面）
• 轻松升级（只需更换容器）
• 轻松测试（在运行测试之前无需进行数据库清理程序） 和其他

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

Answer 2

容器被设计为能够通过使用cgroups来调节资源使用情况，因此只要我们能够预测使用情况，我们在容器中运行它应该没有问题（性能）。然而，除了资源使用之外，还有其他考虑因素。

在 Kubernetes 这样的架构中，管理数据库部署变得更加复杂，部分原因是容器现在是短暂的。如果 pod 在给定节点上出现故障，则无法保证它会在同一节点上恢复，因此需要对有状态应用程序进行特殊考虑（pod 必须在重新启动时安装到同一卷，等等） 。这就是诸如 StatefulSets 之类的构造的用武之地。因此，它有效，并且解决方案是非常经过深思熟虑的，但还有一些操作障碍需要跨越。

还有诸如 Operators 之类的东西可以处理启动和管理有状态应用程序（例如数据库或分布式消息队列）的复杂需求。这些项目有时可能“相当绿色”，但有很多行为很难在我们开箱即用的裸机上编排。 归根结底，在 Kubernetes（或其他容器编排器）上运行数据库或消息队列等有状态应用程序或多或少是一个有争议的话题。与所有设计决策一样，需要在弹性、复杂性和可调试性之间进行权衡。很多大公司都在生产中这样做，所以这绝不是没有道理的。