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

Question

我不知道我的问题到底是从哪里来的，所以我试着解释一下更大的情况。

简而言之，症状是:在将领事从0.7.3升级到0.8.1之后，我的代理程序(下面解释)由于节点In混淆(可能会发生这种情况，下面解释)，无法再连接到集群领导者。我既不能用id修复它，也不能完全理解为什么我会遇到这样的情况。这就是更大的前景，甚至是不同的问题的来源。

我有以下设置：

1. 我运行了一个应用程序栈，大约有8个容器，用于不同的服务(不同的微服务、DB-类型等等)。
2. 我使用每个堆栈的单个领事服务器(是的，领事服务器在软件堆栈中运行，它有其原因，因为我需要它离线部署，并且每个堆栈都是独立的)。
3. 领事服务器处理注册、服务发现和KV/配置。
4. Important/Questionable:每个容器都有一个领事代理，以“consul.d config-dir /etc/ consul . d”开头。连接这台服务器。配置如下..。包括对其他文件的加密令牌/ acl令牌。不要奇怪servicename() ..。在映像构建期间，它被m4宏替换。
5. 客户端由流言密钥和ACL密钥保护。
6. 的重要性：所有容器都在同一个硬件节点上
7. 服务器配置看起来是这样的，如果有任何重要的话。此外，ACL看起来像这样，在配置文件夹中有一个ACL-主文件和客户端令牌/绯闻json文件。

很抱歉，以上可能是TLTR，但所有解释背后的原因是，这个多代理设置(或每个容器一个代理)。

我的理由是：

1. 我使用分蘖来配置容器，所以一个酒窝宝石通常会尝试连接到本地主机:8500。为了避免使领事配置变得非常复杂，我使用了这个本地代理，然后将请求转发给实际服务器，从而处理所有加密密钥/ACL否定内容。
2. 我在服务器上使用了几个“领事监视”任务来触发重新配置，它们也在localhost上运行:8500，没有任何额外的配置。

尽管如此，我运行1代理/容器的原因是，只要本地服务通过127.0.0.1:8500 (作为安全级别)连接，本地服务就可以简单地与领事后端对话，而无需真正了解身份验证。

最后一个问题：

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

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

Answer 1

看起来这个问题已经由Hashicorp识别出来，并在https://github.com/hashicorp/consul/blob/master/CHANGELOG.md#085-june-27-2017中得到了解决，默认情况下，-disable-host-node-id被设置为true，因此节点id不再是从主机硬件生成的，而是一个随机uuid，这解决了我在同一个物理硬件上运行了几个领事节点的问题。

所以我的部署方式很好。