容器与应用程序+数据库

Question

我一直在做一些测试与码头，到目前为止，我想知道为什么它被认为是一个很好的做法，在两个容器中分开数据库和应用程序。

拥有两个容器似乎很麻烦，我也没有看到它的价值。 虽然我喜欢每个应用程序拥有自我可持续容器的想法。

Answer 1

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

它还释放你在不同的地方运行容器，这可能是你的操作的一个限制。或者用不同的应用程序从同一个数据库映像运行多个容器。

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

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

Answer 2

这取决于你认为你的“DB”，它是数据库应用程序还是内容。

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

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

我交付了两个。如果您正在管理容器部署（例如您正在托管应用程序），那么使用多个容器实际上工作量较小。这使您可以将Docker的抽象层用于联网和持久性存储。它还可以在扩展应用程序时提供最大的可移植性（也许您可以考虑使用车队或flocker卷驱动程序或覆盖网络来跨多个服务器托管容器）。如果您正在开发用于分发的产品，交付单个Docker存储库（使用一个映像）会更方便。这可以在您通过部署指导客户时最大限度地降低支持成本。