我刚刚开始了解 Docker，并考虑用 Docker 基础架构替换我的基于 VM 的基础架构。我想知道如何处理容器之间的依赖关系以及如何决定何时/是否需要重新启动依赖容器，如果需要，如何最大限度地减少停机时间。
为了更准确，我发现了 fig 等工具。或 decking管理容器和依赖项，所以(如果我幸运的话)我得到一个有向无环图，它告诉我启动或关闭容器的顺序。例如 mongodb 容器必须在 webserver 容器之前启动。
所以如果我更新 MongoDB 或更改一些设置，我想我也应该关闭网络服务器，因为它不能很好地处理不存在的数据库。在这种情况下，如何最大限度地减少因关闭和重启容器而导致的停机时间，包括重新部署 Jetty webapp 等？
但是，如果我只是更新我的 SMTP 服务器(所有其他容器或多或少都依赖它)，我不希望这会触发我的整个容器基础架构的重启。那么，邮件服务器容器重启后，其他容器是否还能访问之前链接的端口？
你如何处理这种情况？我是否需要/是否可以为每个容器 ABC 添加一个大使容器 ABC_amb，在 ABC 重新启动等时永远不会关闭并保持连接？
最佳答案
所以我认为我首先要做的是，在“硬”和“软”中拆分容器之间的依赖关系。
“硬依赖”意味着 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 地址会更改) .因此，我将使用 serf在启动后/关机前注册和注销 A，将使用 serf event handler触发B上的配置更改，即更新配置文件中A的IP地址并重新加载服务。 (This blog post 介绍了它的工作原理，但要注意它们的设置与我的不同。)
但是，为了不必在每台主机上都这样做，我将使用一个启用 serf 的 HAproxy 服务器作为 A 和 B 之间的大使。B 将使用 链接到这个代理--链接，这样运行在B上的软件就不需要知道任何关于农奴的事情，而是可以依赖DNS连接到大使，代理到A的连接。
A (webapp) <--[soft]-- A_ambassador (haproxy) <--[hard]-- B (nginx)
这似乎是一种可行的方法来保持容器运行，同时(软)依赖容器可以重新启动。一个很好的副作用是(如果事件处理程序脚本编写得很好)，如果存在多个 A 实例，HAproxy 可以作为实际的负载均衡器。
Unresolved 问题:
- HAproxy如何hold connections while the proxied service is down ?
- 在某些情况下，B 还必须重新启动(例如，连接到 A 所需的密码已更改)。或者，A_ambassador 和 B 必须重新启动(例如，A 使用的端口已更改)。如何发现这些情况并妥善处理？
- 为每个服务添加一个额外的 HAproxy 实例的开销可以忽略不计吗？有更轻量级的解决方案吗？
关于dependencies - 如何正确处理 Docker 容器依赖？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25027677/