没有看到大使模式如何增强Docker容器架构的模块化/简单性 [英] Failing to see how ambassador pattern enhances modularity / simplicty of container architecture in Docker

问题描述

我看不出如何实现大使模式将有助于我们简化/模块化我们的容器架构设计。

I fail to see how implementing the ambassador pattern would help us simplify / modularize the design of our container architecture.

假设我有一个数据库容器<$主机A上的c $ c> db ，由位于主机B上的程序 db-client 使用，该主机通过大使容器code> db-ambassador 和 db-foreign-ambassador 通过网络：

Let's say that I have a database container db on host A and is used by a program db-client which sits on host B, which are connected via ambassador containers db-ambassador and db-foreign-ambassador over a network:

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

同一机器中的容器之间的连接，例如 db 到 db-ambassador 和 db-foreign-ambassador 到 db-client 通过Docker的 - 链接参数完成，而 db-ambassador 和 db-foreign-ambassador 通过网络进行交谈。

Connections between containers in the same machine, e.g. db to db-ambassador, and db-foreign-ambassador to db-client are done via Docker's --link parameter while db-ambassador and db-foreign-ambassador talks over the network.

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

But , --link is just a fancy way of inserting ip addresses, ports and other info from one container to another. When a container fails, the other container which is linked to it does not get notified, nor will it know the new IP address of the crashing container when it restarts. In short, if a container which is linked to another went dead, the link is also dead.

为了考虑我的例子，让我们说 db 崩溃并重新启动，因此被分配到不同的IP。 db-ambassador 也必须重新启动，以便更新它们之间的链接...除非你不应该。如果 db-ambassador 重新启动，则IP也将发生更改，而 foreign-db-ambassador 将不知道在新IP地址上找到它。

To consider my example, lets say that db crashed and restarts, thus get assigned to a different IP. db-ambassador would have to be restarted too, in order to update the link between them... Except you shouldn't. If db-ambassador is restarted, the IP would have changed too, and foreign-db-ambassador won't know where to reach it at the new IP address.

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

Quoting an article in the Docker's docs about the ambassador pattern,

当您需要重新连接您的消费者与其他Redis
服务器，您可以重新启动
消费者连接到的redis-ambassador容器。

When you need to rewire your consumer to talk to a different Redis server, you can just restart the redis-ambassador container that the consumer is connected to.

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

This pattern also allows you to transparently move the Redis server to a different docker host from the consumer.

似乎这正是它正在解决的问题。根据我的理解，这完全没有。如果您认为 - 链接只有在链接的容器不会崩溃时才有用。在其以前的IP上启动崩溃节点的选项将是一个很好的解决方法如果支持，至少对于小/中型建筑。

it seems like this is exactly the problem it is trying to solve. Which, as far as my understanding goes, it totally didn't. Not if you consider --link is only useful as long as the linked container doesn't crash. The option to start a crashing node on its previous IP would have been a good workaround if supported, at least for a small/medium sized architecture.

我缺少一些明显的东西？

Am I missing something obvious?

推荐答案

Jérôme有一些好处幻灯片（11-33）关于大使如何比其他方式的服务发现（即DNS，键值存储，绑定安装配置文件等）在他的的jpetazzo / shipping-applications-to-production-in-container-with-docker他也有一些建议，如何解决我想你提到的问题，特别是 Docker Grand Ambassador 看起来很有前途。

Jérôme had some good slides (11-33) on how ambassadors are better than other ways of service discovery (i.e. DNS, key-value stores, bind-mount config file, etc.) in his slide deck on "Shipping Applications to Production in Containers with Docker". He also has some suggestions for how to solve the problem I think you are mentioning, especially Docker Grand Ambassador looks promising.

这篇关于没有看到大使模式如何增强Docker容器架构的模块化/简单性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！