未能看到大使模式如何增强Docker中的模块化/简单容器架构

我没有看到如何实施大使模式将帮助我们简化/模块化我们的集装箱架构的devise。

比方说，我在主机A上有一个数据库容器db ，并由位于主机B上的程序db-client使用，它们通过networking通过大使容器db-ambassador和db-foreign-ambassador连接：

 [host A (db) --> (db-ambassador)] <- ... -> [host B (db-forgn-ambsdr) --> (db-client)] 

在同一台机器上的容器之间的连接，例如db到db-ambassador和db-foreign-ambassador到db-client都是通过Docker的--link参数完成的，而db-ambassador和db-foreign-ambassador在networking上进行通讯。

但是，– --link只是将IP地址，端口和其他信息从一个容器插入另一个容器的奇特方式。 当一个容器发生故障时，与其链接的另一个容器不会得到通知，也不会在重新启动时知道崩溃容器的新IP地址。 总而言之，如果一个连接到另一个的容器死了，链接也就死了。

考虑我的例子，让我们说， db崩溃并重新启动，从而得到分配到不同的IP。 db-ambassador也将不得不重新启动，以更新他们之间的联系…除非你不应该。 如果db-ambassador重新启动，IP也会改变，而foreign-db-ambassador将不知道在新的IP地址到达哪里。

在Docker关于大使模式的文档中引用一篇文章 ，

当您需要重新连线您的客户与另一个Redis服务器交谈时，您可以重新启动客户所连接的redis-ambassador容器。

此模式还允许您将Redis服务器透明地从消费者移动到不同的Docker主机。

看来这正是它正在试图解决的问题。 据我的理解，这完全没有。 不，如果你考虑 – --link只是有用的，只要链接的容器不会崩溃。 如果支持 ，在其以前的IP上启动崩溃节点的选项将是一个很好的解决方法，至less对于中小型体系结构来说。

我错过了什么明显的？

Answer 1

杰罗姆有一些很好的幻灯片（11-33），讲述了大使们在“将应用程序投放到生产中”的幻灯片中比其他服务发现方式（如DNS，键值存储，绑定configuration文件等） 容器与docker“ 。 他对于如何解决我认为你提到的问题也有一些build议，特别是docker大使看起来很有希望。