容器与应用程序+数据库
我一直在使用docker进行一些testing，到目前为止，我想知道为什么在两个容器中分隔数据库和应用程序是一种很好的做法。
有两个容器似乎是麻烦的pipe理，我真的看不到它的价值。 而我喜欢每个应用程序拥有自我可持续容器的想法。
一个原因是数据存储和应用程序的分离。 如果你把它们放在自己的容器中，你可以独立地更新它们。 根据我的经验，这是一个常见的过程，因为通常应用程序的演变速度要比底层数据库快。
它也释放你在不同的地方运行容器，这可能是你的操作的一个限制。 或者使用不同的应用程序从同一个数据库映像运行多个容器。
通常，将UI从一个实例扩展到多个实例也是一件好事，它们都连接到同一个数据库（或caching实例或HTTP后端）。 这在docker最佳实践中被简单地提及。
我也理解在一个容器中运行多个进程的冲动。 这就是为什么像s6这样的极简主义init系统/主pipe最近出现了。 我更喜欢这个用于需要一些东西的应用程序的演示，例如用于前端的nginx，数据库和redis实例。 但是你也可以编写一个基本的docker-compose文件，并用多个容器运行这个demo。
这取决于你认为你的“数据库”，是数据库应用程序还是内容。
后者很容易，内容需要在应用程序的生命周期之外持续存在。 惯例是有一个“数据”容器，简化了它与应用程序的链接（例如，使用Docker引擎创build命令–volumes-from参数）。 在Docker 1.9中，有一个新的卷API取代了“数据”容器的概念。 但是你不应该把你的数据存储在覆盖文件系统中（如果不仅仅是为了持久化，而是为了性能）。
如果您指的是数据库应用程序，那么您确实与微服务人群进入了半宗教的争论。 Docker被构build为运行单个进程。 它是为12个应用程序而devise的。 它是为微服务而构build的。 在一个容器中运行多个进程是绝对有可能的，但是有了它，你必须考虑pipe理/监视这些进程的额外复杂性（例如使用像supervisord这样的初始化进程），处理日志logging等。
我交付了两个。 如果您正在pipe理容器部署（例如，您正在托pipe应用程序），那么使用多个容器实际上是较less的工作。 这使您可以使用Docker的抽象层进行networking连接和持久性存储。 它还可以在扩展应用程序时提供最大的可移植性（也许您可以考虑使用车队或flocker卷驱动程序或覆盖networking来跨多个服务器托pipe容器）。 如果您正在开发用于分发的产品，交付单个Docker存储库（使用一个映像）会更方便。 这可以在指导客户进行部署时最大限度地降低支持成本。