带app + DB的容器

Question

我一直在使用docker进行一些测试，到目前为止，我想知道为什么在两个容器中将数据库和应用程序分开是一种很好的做法。

拥有两个容器似乎很难管理，我真的看不到其中的价值。 虽然我喜欢每个应用程序都有一个自我可持续容器的想法。

Answer 1

一个原因是数据存储和应用程序的分离。如果您将两者都放在自己的容器中，则可以单独更新它们。根据我的经验，这是一个常见的过程，因为通常应用程序将比底层数据库发展得更快。

它还可以让您在不同的地方运行容器，这可能是您操作中的约束。或者使用不同的应用程序从同一数据库映像运行多个容器。

通常，将UI从一个实例扩展到多个实例，所有这些实例都连接到同一个数据库（或缓存实例或HTTP后端）也是一件好事。这在docker best practices中简要提到。

我也理解在一个容器中运行多个进程的冲动。这就是为什么像s6这么多极简主义的初始系统/主管最近出现的原因。我更喜欢这个需要一些东西的应用程序的演示，比如前端的nginx，数据库和redis实例。但您也可以编写一个基本的docker-compose file并使用多个容器运行演示。

Answer 2

这取决于您对“DB”的看法，是数据库应用程序还是内容。

后者很容易，内容需要在应用程序的生命周期之外保留。惯例曾经是一个“数据”容器，它简化了它与应用程序的链接（例如使用Docker Engine创建命令--volumes-from参数）。使用Docker 1.9，有一个新的卷API已经取代了“数据”容器的概念。但是你永远不应该将你的数据存储在覆盖文件系统中（如果不仅仅是为了持久性，而是为了性能）。

如果您指的是数据库应用程序，那么您真的会与微服务人群进行半宗教辩论。 Docker构建为运行单个进程。它专为12个因素的应用程序而设计。它专为微服务而设计。绝对可以在容器中运行多个进程，但是使用它时，您必须考虑管理/监视这些进程的额外复杂性（例如，使用像supervisord这样的init进程），处理日志记录等。

我已经交付了两份。如果您正在管理容器部署（例如，您正在托管应用程序），那么使用多个容器实际上就更少了。这允许您使用Docker的抽象层进行网络和持久存储。它还可以在您扩展应用程序时提供最大的可移植性（也许您可以考虑使用护送或flocker卷驱动程序或覆盖网络来跨多个服务器托管容器）。如果您正在开发用于分发的产品，则交付单个Docker存储库（使用一个Image）会更方便。这可以在您引导客户完成部署时最大限度地降低支持成本。