你应该在 Docker 中运行你的数据库吗
有人提到不在容器中运行数据库，但我不明白为什么会很糟糕……
在容器中运行 PostgreSQL 会导致什么问题？即使您没有很多流量，您是否应该担心？这是一个普遍的事情，如果是这样，为什么这么多应用程序在他们的 docker-compose 文件中设置数据库？
让我们深入研究这个问题，看看哪些因素会影响您的决定，以及您是可以做得更好还是应该开始担心。
在深入潜水之前 - 你知道你真正需要什么吗？
在本地开发环境中使用（或尝试）Docker 时不会三思而后行。毕竟，除了必须回到通常的设置之外，最糟糕的情况是什么？
当涉及到更关键的环境时，使用 Docker 就变得不那么容易了。最后，这一切都取决于您的需求。不是其他人的。你的。
生产对不同的人意味着不同的东西。如果您知道这对您意味着什么，决策就会变得更容易 。你需要什么保证？你愿意承担哪些风险？你需要什么好处，你愿意采取什么权衡？
Docker 开发环境数据库
你应该在 Docker 中运行数据库吗？如果您在开发环境中这样做，则无需担心。
您不会丢失重要数据。如果出现任何问题，您只需从头开始重新创建您的环境。（您可以在一个命令中启动您的开发环境，对吗？）
让我们看看在此设置中使用容器的一些好处：
- 您的开发机器上没有那么混乱
- 您可以并行处理多个项目，这取决于略有不同的数据库版本
- 您可以以可靠的方式在任何操作系统上创建开发环境
- 一切都通过自动化和可复制的“记录”
就个人而言，我现在最喜欢的开发方式是在 docker-compose.yaml 文件中为每个项目定义支持服务，并绑定到主机的本地端口。通过这种方式，我可以在本地运行开发服务器，使用我的工具的全部功能，并让它与容器中的数据库交互。
唯一的缺点可能是团队还不熟悉工具链，需要投入一些研究和调整时间。
我的简单实时应用程序怎么样？
如果您正在处理一个小项目，并且正在部署到一台机器上，那么在 Docker 容器中运行您的数据库是完全可以的。
确保安装一个卷以使数据持久化，并有适当的备份过程。尝试每隔一段时间恢复它们以确保您的备份正常。
许多人使用 Docker 容器运行他们的小项目，或者使用 docker-compose.yaml 文件来启动他们的完整堆栈。它很方便，对于处理非关键数据的小型项目来说非常好。在最坏的情况下 - 您恢复了备份并回到了游戏中。
如果您有一个人们依赖的生产系统，请对这个建议持保留态度，并在下面进一步查看。
陷阱：跨多台机器调度
这是一个非常糟糕的反模式，它会给你带来很多麻烦，即使你只是在做一个小项目。您不应在为无状态应用程序构建的编排工具中运行有状态应用程序。
编排工具旨在处理运行无状态应用程序的 Docker 容器。此类应用程序不介意随时终止，任何数量都可以同时运行而无需相互通信，并且没有人会真正注意到新容器是否会接管不同的机器。
对于数据库来说，这显然不是真的！他们需要他们的数据可用，而被中断可能会造成各种破坏。
如果您使用 Kubernetes 并且您的数据库在 ReplicaSet 或 ReplicationController 中运行，那么这是一个严重的问题。您需要使用 StatefulSets 和 PersistentVolumeClaims。这意味着您的集群应该提供一种创建 PersistentVolumes 的方法，它可以从所有节点访问。
但即便如此，您也不能将任何有状态的应用程序放入 StatefulSet 并完成它。您必须对其进行调整并确保应用程序遵守实际所需的假设。
生产
好的，但是负责任的生产环境呢？在 Docker 容器中运行重要的数据库是个好主意吗？一般来说，我会说不要将 Docker 用于生产数据库。
这里的经验法则是：如何降低复杂性？您的堆栈中的未知数越少，您就越容易维护事物并对事件做出反应。
数据库是关键服务。他们需要努力操作，甚至更努力才能可靠地进行操作。如果你真的需要你的数据留下来并且无论如何都要安全，那么你不想要不必要的风险。
在过去（2016 年），在 Docker 中运行包含有价值数据的数据库会导致问题。
Docker 会崩溃。Docker 会摧毁它接触到的一切。
导致数据损坏的怪异错误的时代可能已经过去，但是在操作关键服务和执行维护任务时，技术堆栈中的多一层可能会导致不必要的陷阱。
特别是如果有其他方法可以获得更高的稳定性，花费更少的精力并降低风险。您的云提供商提供的数据库服务是生产（这也意味着由于生产/暂存奇偶校验）数据库的一种非常好的方式。如果您使用的是 AWS、Digital Ocean 上的托管数据库或云提供商的等效托管数据库服务，请使用RDS。这将简化许多管理任务，例如更新次要版本、处理定期备份甚至扩展。
如果托管数据库服务没有问题怎么办？
所以它是超级重要的数据，太敏感而不能转到托管服务？
是否有真正维护良好的内部 Kubernetes 集群？服务在 k8s 上运行时是否已知处于可靠状态？将 Kubernetes 用于所有事情是否有实际重要的商业原因？也许。但我还是会很犹豫。
在所有其他情况下，请考虑跳过 Docker，并为数据库集群的每个部分使用专用机器，从而尽可能降低操作复杂性。
综上所述
Docker 非常适合在开发环境中运行数据库！您甚至可以将它用于在单个服务器上运行的小型、非关键项目的数据库。只要确保有定期备份（在任何情况下都应该这样做），你会没事的。
出于对所有好处的热爱 - 不要在容器编排/调度工具中运行 dockerized 数据库，而不确保它们可以处理有状态的应用程序。可能默认情况下他们不会这样做，您会看到很多奇怪的问题。即使可以，您通常也需要调整应用程序以与相关工具兼容。
您应该将 Docker 用于生产数据库吗？不。仅仅是因为有更好的选择，例如由您的云提供商管理的数据库服务。如果您真的必须以可靠的方式自行托管此类服务，那么您需要进行大量的工作和学习。设置专用机器并跳过 Docker。这是一个很棒的工具，但在这种情况下，您可能不需要它可以提供的好处。