Docker，注册人和领事

我对Docker和Consul都是新手，并且试图了解容器化应用如何将Consul用于服务注册和KVconfigurationpipe理（“configuration”）。

我的理解是我可以：

• 创build一个运行Consul服务器的映像，像这样 ; 然后
• 在myvm01.example.com （一个Ubuntu VM）上myvm01.example.com三个这样的Docker-Consul容器（从而形成一个集群/仲裁）。 然后
• 重构我的应用程序使用Consul并创build一个运行我的应用程序和Consul代理的Docker镜像，其中代理configuration为在启动时join3节点仲裁。 在启动时，我的应用程序使用本地Consul代理将其所有configuration下拉为KV对。 它还提供注册/健康服务，并使用本地负载均衡工具来平衡其集成的服务。
• 在myvm02.example.com （另一个Ubuntu VM）上运行我的应用程序的容器。

所以，首先，如果这似乎是我误解了docker工人和领事（正式注册人）的正常使用，请首先纠正我！

假设我或多或less是正确的，我最近偶然发现注册者 ，现在更加困惑。 注册人似乎是你的应用程序容器和你的领事（或者你使用的任何registry）服务器之间的一些中间人。

阅读他们的快速入门教程后， 听起来像你应该做的是：

• 像以前一样将我的Consul集群/仲裁容器部署到myvm01.example.com
• 而不是“Dockerizing”我的应用程序直接使用Consul，我只是将它与registry集成
• 然后，我在某个地方部署一个注册器容器，并将其configuration为与Consul集成
• 然后我部署我的应用程序容器。 他们与注册机构整合，而注册机构又与领事整合。

我的担忧：

• 我的理解是正确还是偏离基础？ 如果是这样，怎么样？
• 实际上通过增加注册人获得了什么。 对于应用程序和服务registry之间的一层间接寻址，似乎并不是（至less对于未经过培训的人）。
• 我是否仍然可以通过注册人利用Consul的KVconfiguration服务？

Answer 1

我的理解是正确还是偏离基础？ 如果是这样，怎么样？

在我看来，这不是一个好的解决scheme，让所有群集/仲裁成员在同一个虚拟机内运行。 如果你把它用于开发或者testing或者其他一些你不太在乎可靠性的东西，那也不是什么坏事，但是对于生产来说不是很在乎。

一旦你的虚拟机死了，你将失去创build集群的所有优点。 甚至更多的，你可以放弃你在K / V商店中的所有数据，因为你正在docker集装箱里面运行Consul服务器，它应该被另外地configuration来共享运行之间的configuration。

至于其余的，我看到它和你一样。

实际上通过增加注册人获得了什么。

从我的观点来看，最重要的是，您不必在每个运行的容器中都提供一个Consul Agent实例。 而运行映像的容器只负责其主要function，而不是在某处注册。 你可以简单地拉一个图像，只是运行一个容器，使其服务可用，无需额外的工作。

我是否仍然可以通过注册人利用Consul的KVconfiguration服务？

很不幸的是，不行。 至less，我们没有find解决scheme来使用它，当我们正在寻找一些服务发现和configurationpipe理。 我们得出的结论是，注册人不是K / V商店的代理，仅用于自动化服务发现。 所以你必须使用一些其他逻辑来访问领事的K / V商店。

更新：此外，这里有2篇文章： “自动的与注册人的Docker服务公告”和“与Consul和Registrator自动注册容器” ，我发现有用的理解注册人在服务发现过程中的angular色。