我不确定问题的根源究竟来自哪里，所以我试着解释一下大局。
简而言之，症状：在将领事从0.7.3升级到0.8.1之后，我的代理（解释如下）由于dublicated node-id而无法再连接到集群领导者（为什么会发生这种情况，如下所述） 。 我既不能用https://www.consul.io/docs/agent/options.html#_disable_host_node_id修复它也不能完全理解，为什么我会碰到这个..那就是更大的图景甚至是不同的问题来自哪里。
我有以下设置：
我运行一个包含大约8个容器的应用程序堆栈，用于不同的服务（不同的微服务，数据库类型等）。
我每个堆栈使用一个consul服务器（是的，consul服务器在软件堆栈中运行，它有其原因，因为我需要它可以脱机部署，并且每个堆栈都适合自己）
< / LI>consul-server确实处理注册，服务发现以及KV /配置
重要/可疑：每个容器都有一个以“consul agent -config-dir /etc/consul.d”开头的consul代理程序..连接这个服务器。配置看起来像这样..包括他们加密令牌/ acl令牌的其他文件。不要怀疑servicename（）..它在图像构建时被m4宏取代
客户端受八卦密钥和ACL密钥保护
重要提示：所有容器都位于同一硬件节点上
如果有任何重要的话，服务器配置如下所示。此外，ACL看起来像这样，并且ACL-master和客户端令牌/八卦json文件位于该configurtion文件夹中
很抱歉这可能是上面的TLTR，但所有解释背后的原因是，这个多代理设置（或每个容器1代理）。
我的理由：
我使用tiller来配置容器，所以dimploy gem会尝试通常连接到localhost：8500 ..以便在不使consul-configuration非常复杂的情况下完成，我使用这个本地代理，然后转发请求到实际服务器，从而处理所有加密密钥/ ACL否定的东西
我在服务器上使用了几个“consul watch”任务来触发重新配置，它们也可以在localhost：8500上运行，无需任何额外配置
也就是说，我运行1代理/容器的原因是，本地服务与consul-backend交谈的简单性，只要它们通过127.0.0.1:8500连接而不知道身份验证（作为级别安全）
最终问题：
那个多领事代理人是否真的被设计成以这种方式使用？我问的原因是，因为据我所知，我在启动0.8.1时得到的node-id复制问题来自“主机”是相同的，所以硬件节点对于所有的consul-agent都是相同的。对吧？
我的设计是错误的还是我需要从现在开始生成自己的节点ID并且一切正常？
答案 0 :(得分：0)
似乎这个问题已被Hashicorp识别并在https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#085-june-27-2017中解决，其中默认情况下-disable-host-node-id已设置为true，因此不再从主机硬件生成node-id，而是随机生成uuid，它解决了我在同一物理硬件上运行几个consul节点的问题
所以我部署的方式很好。