Docker 领事代理架构。。升级到0.8.1后的节点id问题-概念问题？

我不确定我的问题的根源到底来自哪里，所以我试图从更大的角度来解释

简言之，症状是：在将concur从0.7.3升级到0.8.1之后，由于节点ID不可靠，我的代理（解释如下）无法再连接到集群领头节点（原因可能是这样的，解释如下）。 我既无法解决问题，也无法完全理解我为什么会遇到这种情况。。这就是大局，甚至是不同问题的来源

我有以下设置：

我为不同的服务（不同的micoservices、DB类型等）运行了一个包含大约8个容器的应用程序堆栈

我在每个堆栈中使用一个concur服务器（是的，concur服务器在软件堆栈中运行，它有它的原因，因为我需要离线部署，并且每个堆栈都独立存在）

Concur服务器处理注册、服务发现和配置

重要/可疑：每个容器都有一个以“consur agent-config dir/etc/consur.d”开头的consur代理。。将服务器连接到此服务器。配置如下所示。。包括使用加密令牌/acl令牌的其他文件。不要怀疑servicename（）。。在映像构建期间，它被m4宏替换

客户端由gossip密钥和ACL密钥保护

重要提示：所有容器都位于同一硬件节点上

服务器配置看起来像这样（如果有任何重要的话）。此外，ACL如下所示，配置文件夹中有ACL主令牌和客户端令牌/json文件

---

很抱歉，上面可能是TLTR，但所有解释背后的原因是，这种多代理设置（或每个容器1个代理）

我的理由是：

我使用tiller来配置容器，因此dimploy gem通常会尝试连接到localhost:8500。。为了在不使concur配置异常复杂的情况下实现这一点，我使用了这个本地代理，然后它将请求转发到实际的服务器，从而处理所有加密密钥/ACL否定的内容

我在服务器上使用了几个“Consor watch”任务来触发重新配置，它们也在localhost:8500上运行，没有任何额外的配置

也就是说，我运行1-agent/container的原因是，本地服务只需通过127.0.0.1:8500（作为安全级别）进行连接，就可以简单地与领事后端通信，而不必真正了解身份验证

最后一个问题：

多领事代理真的是这样设计的吗？我问这个问题的原因是，据我所知，我现在在启动0.8.1时遇到的节点id重复问题来自于“主机”相同，因此所有Consor代理的硬件节点都相同。。对吧?

---

我的设计是错误的还是我需要从现在开始生成自己的节点id，而且一切都很好？

似乎Hashicorp已经发现了这个问题，并在其中解决了这个问题，默认情况下，

-disable host node id

已设置为true，因此节点id不再从主机硬件生成，而是一个随机uuid，这解决了我在同一个物理硬件上运行多个concur节点的问题

所以我部署的方式很好