7

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

更准确地说，我发现了诸如fig或decking之类的工具来管理容器和依赖项，因此（如果我幸运的话）我得到了一个有向无环图，它告诉我启动或关闭容器的顺序。例如，mongodb 容器必须在 webserver 容器之前启动等。

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

但是，如果我只是更新我的 SMTP 服务器（或多或少所有其他容器都依赖），我不希望这触发我的整个容器基础设施的重新启动。那么，重新启动邮件服务器容器后，其他容器是否仍然能够访问之前链接的端口？

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

4

1 回答 1

2

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

“硬依赖”意味着 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 事件处理程序来触发 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 实例的开销可以忽略不计吗？有更轻量级的解决方案吗？
于 2014-08-08T03:56:33.153 回答