我正在和一个朋友讨论Docker用例。团队中的一个人想将Docker用于一切-就像一种通用的unix进程包装器。另一位认为Docker应该仅用于无状态应用程序，例如微服务和AWS Lambda风格的应用程序。

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

尽管有相反的证据，我的朋友仍然坚持他的立场。 （他还辩称，Docker通过增加堆栈的复杂性而增加了不必要的风险。）和他一起。 （我们都相处得很好-因此，这是疯狂和认真讨论的结合）。

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

我的问题是：不应该将Docker用于数据库的原因是什么？

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

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

评论

stackoverflow.com/a/52963747/2777965
该博客的作者认为，由于云提供商提供托管数据库，因此不应在容器内运行数据库。

#1 楼

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

卷在Docker中是必不可少的一部分，而不是易碎的或刚沾上的东西。 Docker不仅适用于无状态（微）服务。

我希望，我找不到在Docker中不运行数据库的技术原因，所以不幸的是，我将选择该参数，因此可能无法为您提供所需的答案。如果您超过默认设置，操作起来将变得很简单，这就是一个臭名昭著的野兽。）


将DB软件本身打包在容器中可为您带来通常的好处-拥有到处都有相同的版本，避免了依赖关系/共享库问题，能够在开发人员笔记本电脑或您需要的任何地方启动完全相同的数据库。
让它可以在任何地方运行都是很容易的；更新是微不足道的，依此类推。所有Docker优势都适用。 Dockerhub上有一个Oracle映像，它允许您在一到三分钟内启动一个可用的数据库（当然，对于其他数据库也是如此）。卷和裸机（https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/，https://stackoverflow.com/questions/21889053/what-is-the-
在后台，这并不像Docker以某种方式截获所有I / O。它只是通过标准Linux工具（在这种情况下为绑定挂载，对使Docker-fu成为可能的内部内核表进行处理）而具有创造力。
显然，这并不意味着您可以运行两个数据库实例并使它们在同一文件上运行，但是没有人暗示这一点。 Docker不会为您提供自动同时且神奇地无竞争地访问卷的功能，并且从未假装这样做。其余好处仍然适用。如果您的数据库本身未检测到这样的冲突，则最好为映像提供CMD脚本，该脚本拒绝在已使用该卷时拆分第二个容器。关闭容器（就像您不会简单地关闭裸机数据库服务器一样），但这应该是很容易管理的。 ：例如，如果您在Docker容器中运行Oracle的RDBMS，则Oracle（该公司）当然将不支持您。但是也许您仅将dockerized Oracle RDBMS映像用于开发人员和测试环境，在任何情况下都不需要它们的支持，因此可以将其保留用于裸机生产服务器。 （但不要忘了支付您的许可证...）。
如果运维人员不熟悉Docker，则意外杀死所有内容，销毁数据文件等可能会更容易一些。 >如果您已经拥有大型专用金属DB计算机，并且具有大量非常快速的专用SAN存储，并且无论如何都无法运行，那么使用Docker对其进行容器化就没有意义了，因为您永远不会在那时启动另一个服务器是数百GB甚至TB的数据。毕竟，对于生产而言，像Oracle的RDBMS在所有复制，数据完整性，无停机故障转移等方面都非常非常先进。请注意，此参数仅表示“您不需要容器化RDBMS”。它没有说“您不应该这样做”-也许您想这样做是因为您希望通过容器或您可以想象的任何其他原因推出数据库软件升级。

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

评论

另一个因素是，替代方案是使用托管数据库服务还是托管自己的数据库服务。

–avi
19年3月16日在21:18

#2 楼

我对此进行了深入介绍，但摘要如下：预防裂脑（选择多个主节点）需要解决。否则可能会造成灾难性的后果
没有可用的生产就绪共享存储解决方案可以使数据库在一个实例上关闭并在另一个实例上启动而不会丢失所有数据。

评论

谢谢-这几乎是一个合理的答案。但是，在您的博客文章中，您添加了一个警告，以验证我在上面写下的假设。 “下面列出的问题与仅在没有共享存储的docker中运行数据库或无法在其他节点上自动启动数据库有关。”即，您的博客文章说我上面写的情况是正确的。

–鹰眼
17年6月6日在10:50
从您的问题看来，您似乎正在使用某种编排来启动数据库并装入卷。但是，您在业务流程方面存在一个潜在的一致性问题，我正在谈论。我需要特别注意的是您什么时候不使用业务流程。

–机器人
17年6月6日在10:58
你看过flynn.io吗？据称它们已经准备好生产，并且通过使用Chorum状态机（基于Joyent Manatee）避免了裂脑情况。

– Alix Axel
17年7月10日在16:55
这些观点都不适用于cassandra或其他分布式数据库，但我仍然认为在容器中运行它不是一个好主意。

–dres
17年9月6日在1:54

#3 楼

当您说数据已装入Docker容器时，说“数据库”已装入Docker容器是否更正确？如果您要将数据保留在容器之外，那么您正在做的“正确”的事情是不将数据库放入容器中。我个人认为您存储在外部的数据是很好的设计，因为它在逻辑和数据之间保持了清晰的分隔。但是，一旦将数据放入一个容器中，它们就可能起火了。纠缠在一个容器中。