在 Docker 容器中运行数据库，还是在物理服务器上运行？

Question

数据库被设计为使用所有可用的内存、CPU和IO资源。在生产环境中，Docker是否适合用于数据库？有哪些好坏原因？

也许这个问题也适用于其他工具，如MOMs Apache Kafka、Apache ActiveMQ等。

- Player_Neo

Answer 1

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

Docker唯一额外的负担就是在内核之上加载另一个操作系统，但实际上大多数容器都使用非常轻量级的东西，比如alpine Linux，因此我认为这不必考虑。

从另一个角度来看，将数据库（或任何其他高负载服务）放入容器中具有以下优点：

• 扩展性（容器可轻松地通过容器编排工具（如k8s）分散在节点之间）
• 易于部署（所有依赖项均在容器内）
• 易于升级（只需更换容器）
• 易于测试（无需在运行测试之前进行数据库清理程序）和其他

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

- grapes

---

总结你的答案，将应用程序（Spring、Python、NodeJS等）部署为Docker容器，并通过K8s进行管理。但是像DB服务器、MoMs等应用程序在生产环境中需要在裸机服务器上运行。 - Player_Neo

@BhanuHoysala 这是一个非常有争议的话题。您可以使用Persistent Volumes、Shared Storage Pools和Affinity规则来使k8s处理数据库存储“良好”。其想法是-k8s是您与基础架构中所有可能应用程序交互的API接口，而不是针对每个单独事物的一次性脚本。 - OneCricketeer

Answer 2

容器旨在通过使用cgroups来调节资源使用，因此只要我们能够预测使用情况，就不应该有性能问题。然而，除了资源使用之外，还有其他考虑因素。

在像Kubernetes这样的架构中，管理数据库部署变得更加复杂，部分原因是容器现在是短暂的。如果一个Pod在给定节点上崩溃，不能保证它将在同一节点上重新启动，因此需要为有状态的应用程序做出特殊考虑（例如，必须在重新启动时将Pod挂载到相同的卷上）。这就是StatefulSets等结构发挥作用的地方。因此，它可以工作，解决方案也经过了非常深思熟虑，但仍需跨越一些操作障碍。

还有像运算符这样的东西，可以处理像数据库或分布式消息队列这样的状态应用程序的复杂需求。这些项目有时可能会相当新颖，但是我们可以在开箱即用时获得很多难以在裸机上编排的行为。

总的来说，在Kubernetes（或其他容器编排器）上运行类似数据库或消息队列之类的有状态应用程序是一个有争议的话题。像所有设计决策一样，它具有弹性、复杂性和可调试性方面的权衡。许多大型公司正在生产中使用它，因此它绝不是不合理的。

- Monkeyanator