Docker不应该用于数据库的原因是什么？

我正在和一个朋友讨论Docker用例。团队中的一个人想使用Docker来完成所有工作-就像一种通用的unix进程包装器。另外认为，应该多克仅用于无状态的类似应用微服务和AWS LAMBDA风格的应用程序。

我们为两者设计了概念证明。在我们的Docker集群上，我们有一个共享驱动器，该驱动器在Docker主机安装时就被挂载了，如果在容器中的数据库被挂载了，它只会将一个卷挂载到共享驱动器上。

尽管有相反的证据，我的朋友仍然坚持他的立场。（他还指出，Docker通过增加堆栈的复杂性而增加了不必要的风险。）

无论是出于同理心，还是与他更好地推理，我都试图倾听并理解他的观点。（我们都相处得很好-因此，这是疯狂和认真讨论的结合）。

问题背后的一种问题是：数据库是牛吗？此注释表明，对于数据库而言，良好的自动备份和检索策略与牛服务器是无法区分的。

我的问题是：为何不应该将Docker用于数据库？

编辑： 人们要求我阐明我的术语。我以为数据库应用程序位于容器中，而存储位于卷中。我的意思是，RDBMS位于容器中，而数据库存储位于卷中。

一些评论者建议docker卷驱动程序不能很好地处理数据库写入。（或类似的东西）。您能对此进行扩展吗？

人们谈论在Docker中运行数据库时，并不意味着要将数据存储在容器中。他们正在谈论使用DB软件安装docker映像，并将数据作为卷安装（绑定卷，而不是容器卷）。

卷是Docker中必不可少的部分，不是易受攻击的东西。码头工人是不是只为无状态（微）服务方面。

就像我可能希望的那样，我找不到在Docker上不运行数据库的技术原因，因此不幸的是，我选择了论点的另一面，因此可能无法为您提供所需的答案。

（我以Oracle为例，因为我对裸机和docker化技术都非常熟悉，并且因为它是一个臭名昭著的野兽，因为如果您超过默认设置，操作起来会很麻烦。）

• 将数据库软件本身打包在一个容器中，将为您带来通常的好处-到处都有相同版本，避免依赖项/共享库问题，能够在开发人员笔记本电脑或您需要的任何地方启动完全相同的数据库。
• 使它可以在任何地方运行都是很容易的。更新是微不足道的，依此类推。所有Docker优势都适用。Dockerhub上有一个Oracle映像，它允许您在一到三分钟内启动一个正常工作的数据库（当然，对于其他人也是如此）。
• 人们没有做性能测试，发现卷和裸机之间没有I / O的差异（https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/，https：//开头计算器.com / questions / 21889053 / what-is-the-run-time-performance-cost-of-a-docker-container）。
• 在幕后，无论如何，这并不像Docker以某种方式拦截所有I / O。它只是通过标准Linux工具（在这种情况下为绑定挂载，对使Docker-fu完全有可能的内部内核表进行处理）而具有创造力。
• 显然，这并不意味着您可以运行两个数据库实例，并使它们在同一文件上工作，但是没有人暗示这一点。Docker不会为您提供自动同时且神奇地无竞争地访问卷的功能，并且从未假装这样做。其余好处仍然适用。如果您的数据库本身未检测到这样的冲突，则最好向映像提供一个CMD脚本，该脚本拒绝在卷已被使用时旋转第二个容器。
• 您必须更加小心地旋转/关闭容器（就像您不会简单地关闭裸机DB服务器一样），但这应该是很容易管理的。

现在，视情况而定，可能有柔和的理由不这样做：

• 例如，如果在Docker容器中运行Oracle的RDBMS，则Oracle（该公司）当然不会支持您。但是也许您仅将dockerized Oracle RDBMS映像用于开发人员和测试环境，在任何情况下都不需要它们的支持，因此可以将其保留用于裸机生产服务器。（但不要忘记支付您的许可证...）。
• 如果运维人员不熟悉Docker，则意外杀死所有内容，销毁数据文件等可能会更容易一些。
• 如果你有大的专用金属DB机已经与大量的非常快速的专用的SAN存储，运行闲来无事反正话，那就只是没有任何意义使用泊坞窗以containerize 那些因为你永远只旋转另一台服务器最多时，有是数百GB甚至TB的数据。毕竟，对于生产而言，像Oracle的RDBMS在所有复制，数据完整性，无停机故障转移等方面都非常非常先进。请注意，此参数仅表示“您不需要容器化RDBMS”。它没有说“您不应该这样做”-也许您想这样做是因为您希望通过容器或您可以想象的任何其他原因推出数据库软件升级。

所以你去了。通过各种手段做 dockerize您的数据库，至少是对你的开发者（谁将会永远感激）和你的测试环境。在生产中，它会逐渐变味，至少在那儿，我也更喜欢与专门的DBA / Ops配合使用的最佳解决方案-如果他们有数十年的裸机DB服务器工作经验，那么一定要信任他们继续这样。但是，如果您是一家无论如何都将所有IT都存储在云中的初创公司，那么Doc​​ker容器将只是整个情况的另一部分。

我对此进行了深入的介绍，但这是摘要：

• 防止大脑分裂（选择多个主节点）需要解决。否则可能会造成灾难性的后果

• 没有可用的生产就绪共享存储解决方案来使数据库在一个实例上关闭并在另一个实例上启动，而又不会丢失所有数据。

当您说数据已装入Docker容器时，说“数据库”已装入Docker容器是否更正确？如果您要在容器外部保留数据，那么您正在做的“正确”的事情是不将数据库放入容器中。

当然，到镇上将DBMS放在容器中，让它管理您存储在外部的数据，就我个人而言，我认为这是一个很好的设计，因为它可以使逻辑和数据之间保持清晰的分离。但是，一旦将数据放入容器中，您就可能在玩火。

尽管容器存储驱动程序已经走了很长一段路，但我个人还不愿意深入研究并将数据纠结在容器中。