如何正确处理Docker容器依赖关系？

Question

我刚刚开始了解Docker，并考虑将基于VM的基础结构替换为Docker基础结构。我想知道如何处理容器之间的依赖关系，以及如何决定何时/是否需要重新启动依赖容器，如果需要，如何最小化停机时间。

更准确地说，我发现了诸如图2或铺装之类的工具来管理容器和依赖项，所以(如果幸运的话)我会得到一个有向无圈图，它告诉我启动或拆卸容器的顺序。例如，mongodb容器必须在webserver容器之前启动，等等。

因此，如果我更新MongoDB或更改某些设置，我想我也应该关闭well服务器，因为它不能很好地处理数据库不存在的问题。在这种情况下，如何尽量减少关闭和重新启动容器所造成的停机时间，包括重新部署Jetty等？

但是，如果我只是更新我的SMTP服务器(几乎所有其他容器都依赖它)，我不希望它触发我的整个容器基础结构的重新启动。因此，在重新启动邮件服务器容器后，其他容器是否仍然能够到达先前链接的端口？

你是如何处理这种情况的？我是否需要/是否有可能为每个容器添加一个大使容器ABC_amb，这些容器ABC在ABC重新启动时永远不会下降并保持连接？

Answer 1

因此，我想我首先要做的是，在“硬”和“软”中分割容器之间的依赖关系。

“硬依赖”意味着B非常依赖于A，如果A是重新启动的，那么B也必须重新启动。(可能是因为在启动时存在依赖于B状态的网络连接。)在这种情况下，我将以一种尊重依赖性的方式重新启动容器:关闭B，然后A，然后启动A，最后B。这就是无花果和包装可以做得很好的地方。

“软依赖”意味着B使用来自A的服务，但如果A重新启动，则不需要重新启动B。(典型的用例是B上的web代理，用于A上的web应用程序)在这种情况下，我只会重新启动A和保持B运行。

对于软依赖项，我不能使用Docker --link参数，因为在重新启动A之后，B所知道的A的DNS名称将指向任何地方(IP地址在容器重新启动时更改)。因此，我将在启动/关闭前使用农奴注册和注销A，并将使用serf事件处理程序在B上触发配置更改，即在配置文件和重新加载服务中更新A的IP地址。(这篇博客文章介绍了它的工作原理，但请注意，它们的设置与我的不同。)

但是，为了不需要在每台主机上都这样做，我将使用一个支持服务器的HAproxy服务器，它充当A和B之间的大使，B将使用--link链接到这个代理，这样运行在B上的软件就不需要了解任何关于serf的信息，而是可以依赖DNS连接到大使，这将代理到A的连接。

  A (webapp)   <--[soft]--  A_ambassador (haproxy)  <--[hard]--  B (nginx)

这似乎是保持容器运行的可行方法，而依赖(软)依赖的容器可以重新启动。一个很好的副作用是(如果事件处理程序脚本编写得很好)，如果存在多个A实例，HAproxy可以作为实际的负载均衡器工作。

未决问题：

• HAproxy 在代理服务关闭时保持连接如何
• 在某些情况下，B还必须重新启动(例如，连接到更改的A所需的密码)。或者，A_ambassador和B必须重新启动(例如，A所使用的端口已更改)。如何发现和妥善处理这些案件？
• 每个服务添加一个额外的HAproxy实例的开销是否可以忽略不计？是否有更轻量级的解决方案可用？