Consul-Agent架构..升级到0.8.1后的node-id问题 – 概念问题？
我不知道我的问题的根源究竟在哪里，所以我试图解释更大的图片。
简而言之，症状：将代理从0.7.3升级到0.8.1后，我的代理（下面解释）由于公布的节点ID（为什么可能发生，下面解释），不能再连接到群集领导。 我既不能解决它与https://www.consul.io/docs/agent/options.html#_disable_host_node_id也不完全理解，为什么我遇到这个..那是更大的图片，甚至可能是不同的问题来自哪里。
我有以下设置：
-
我运行一个应用程序堆栈约8个容器为不同的服务（不同的micoservices，数据库types等）。
-
我使用一个单一的领事服务器每个堆栈（是的领事服务器运行在软件堆栈，它有其原因，因为我需要这是离线可部署的，每个堆栈生活本身）
-
领事服务器确实处理注册，服务发现以及KV /configuration
-
重要/可疑：每个容器都有一个以“consul agent -config-dir /etc/consul.d”开头的consul代理。连接这个服务器。 configuration看起来像这样..包括其他文件与他们encryption令牌/ acl令牌。 不要怀疑servicename（）..它在图像构build时被一个m4macros所取代
-
客户端由八卦键和ACL键保护
-
重要提示：所有容器都在同一个硬件节点上
-
服务器configuration看起来像这样，如果有的话。 另外，ACL看起来像这样，一个ACL-master和client token / gossip json文件在这个configuration文件夹中
对不起，这可能是TLTR上面，但所有解释背后的原因是，这个多代理设置（或每个容器1代理）。
我的理由是：
-
我使用tiller来configuration容器，所以一个dimploy gem会尝试通常连接到localhost：8500 ..以表明，在不使consul-configuration非常复杂的情况下，我使用这个本地代理，然后将请求转发给实际的服务器从而处理所有的encryption密钥/ ACL否定的东西
-
我在服务器上使用了几个“consul watch”任务来触发重新configuration，他们也在localhost：8500上运行，没有任何额外的configuration
也就是说，我运行1代理/容器的原因是，只要通过127.0.0.1:8500（作为安全级别）连接，本地服务就可以简单地与后端对话，而不必真正了解身份validation，
最后的问题：
这个多领事代理人是否devise成这样使用？ 我所要问的原因是，因为据我所知，当我开始一个0.8.1的时候，我得到的node-id重复问题来自于“主机”，因此所有的consul-agent的硬件节点是相同的。 。 对？
我的devise是错误的，还是需要从现在开始生成我自己的node-id？