将数据库保存在容器中是一种反模式吗？

Question

我对容器的最佳做法有疑问。 在容器中具有数据库是一种反模式吗？

我已经看过几次在容器中实现DB的实现，并且我很想得到大家的想法。据我了解，容器应该是轻量级的并且实际上是无状态的。它们还应该像牛一样，而不是宠物（因为它们很容易被破坏，并且您不依靠一个容器来执行业务功能）。

根据我对DB的了解，它们通常不是牛，并且根据应用程序的不同，它们也不是轻量级的。它们本质上也具有状态。

很明显，我对将DB托管在容器中表示怀疑，但是我真的很想听听大家的想法。我对DBA的工作不太熟悉，因此听取那些有更多经验（尤其是如果您已经实施并且有经验可以与之交谈的人）的人来听。

Answer 1

这是一个很好的问题，尽管有点广泛。这完全取决于您正在运行什么，以及如何计划工作量。

关于容器要牢记的一点是，这里确实没有任何魔术。容器最终归结为对进程施加的内核级别（cgroup）限制，而业务流程层（例如Kubernetes或CloudFoundry Diego）负责应对容器因超出这些限制而被杀死的情况（例如内存不足）。 >

通常，需要牢记许多高级因素

• 该项目的数据持久性要求是什么
• 工作量是多少（例如每小时高峰，不可预测的负载等）
• 您的正常运行时间服务水平协议（SLA）是什么？您的客户能否优雅地处理故障转移到数据层中的新主服务器
• 最重要的是，容器化是您项目数据层要实现的正确模式。

除此之外，您还必须查看业务流程环境的特征。如果需要能够保留磁盘内容，则需要确保选择一个能够满足此要求的容器协调器。

您可能有一个类似的MongoDB分片群集，它使用内存中的引擎作为缓存层，与典型的键值存储（如memcache）相比，它需要更多的功能（例如查询/过滤缓存本身的能力）。根据项目的要求，丢失此“缓存”层并按需​​重建它可能会很好。

在其他工作负载中。您可以运行诸如enterpriseDB ARK之类的东西，以在Kubernetes上提供群集的，高可用性的，容器化的PostgreSQL部署。这带来了自己的挑战，但是它使您能够在微服务体系结构中实现服务代理模型，以减轻易受邻居干扰的整体式数据层的方式为每个微服务部署和持久化数据层。这种体系结构中的问题。