Architecture 从容器中发布应用程序(docker)

Architecture 从容器中发布应用程序(docker),architecture,docker,service-discovery,linux-containers,Architecture,Docker,Service Discovery,Linux Containers,我在周末问了这个问题,但在我想清楚答案之前,我不得不离开: 如果我有许多应用程序在容器中运行(让我们暂时假设它们都在同一个物理硬件上运行,但不必如此),我希望它们中的每一个都能够自动找到彼此 使用某种类型的注册表(例如DNS-SD/Bonjour),您可以宣布您的服务和任何相关细节,并让其他应用程序了解它们并相应地路由流量 这里的问题是,虽然应用程序可以知道它在容器中服务于哪个主机名/端口,但这不一定是它可以访问的端口或地址。有两个信息位需要合并: 其中可以访问服务;可从容器外部进入 服务的功

我在周末问了这个问题,但在我想清楚答案之前,我不得不离开:

如果我有许多应用程序在容器中运行(让我们暂时假设它们都在同一个物理硬件上运行,但不必如此),我希望它们中的每一个都能够自动找到彼此

使用某种类型的注册表(例如DNS-SD/Bonjour),您可以宣布您的服务和任何相关细节,并让其他应用程序了解它们并相应地路由流量

这里的问题是,虽然应用程序可以知道它在容器中服务于哪个主机名/端口,但这不一定是它可以访问的端口或地址。有两个信息位需要合并:

  • 其中可以访问服务;可从容器外部进入
  • 服务的功能(版本号、服务类型);可从容器内部进入
您建议我如何通过容器屏障获取此信息

  • 我可以通过TCP向容器公开docker,这样应用程序就可以查询它的显示位置,但这似乎违反了关注点分离
  • 我可以在容器中打开一个文件/端口,主机系统在容器启动后查询该文件/端口以准备发布,但这感觉有点像是我在重新创建WSDL

  • 关于如何解决此问题,您有什么想法或指导吗?

    我认为可能是在启动容器后执行服务注册的方法。然后,其他容器可以执行注册表查找以发现这些服务

    更新
    该项目给出了一个示例,说明如何在外部配置容器,然后启动容器以建立一个协作的容器网络。

    我在这方面也遇到了问题。我相信你的想法是错误的,容器本身是唯一知道它做什么的人

    容器不是现在为MySQL服务的自我感知实体,它们决定明天成为队列处理器

    相反,这里有一个控制器(可能只是一个自动化系统,也可能是您在命令行上),该控制器知道某个特定的应用程序应该运行,要运行该应用程序,需要一组特定的服务,这就是为什么首先启动容器

    控制器知道需要一个MySQL服务,并且MySQL服务代表一个主机:要连接的端口。如果是这种情况,它还可能知道一个服务由两个或三个端口组成

    因此,主机/控制器告诉容器要注册哪个地址,或者询问它在哪个本地端口上提供服务(或者更可能根据容器定义知道端口),在体系结构上是正确的

    实际上,主机可能会告诉容器“在这个特定端口上的LAN接口上运行您的服务,我会注册它”,“在这个LAN接口上的任何端口上运行您的服务,然后自己注册”或者“在这个端口上运行您的服务,然后在host:port上注册它,我会设置映射以确保它在那里可用”

    所有这些在体系结构上都是好的:最终,主机/控制器总是决定的,因为它实际上是唯一一个知道运行什么服务以及在哪里可以访问它们的人

    我发现docker中的一个实际问题是,容器IP和主机映射端口是以这样一种方式动态分配的,直到容器运行之后,您才能真正获得这两种信息;这就是为什么选择主机端口映射本身,而不是让docker自动进行映射


    对此我有一些想法。

    这就是我在编号为“2”的一点中试图(拙劣地)解释的内容。如果我等到容器启动之后,我可以让主机系统进行注册,但是我没有统一的方法来确定容器做什么。(容器中包含的服务类型和版本等信息不易获取)。@JP。明白了,这是鸡和蛋的问题。我认为没有任何有效的方法来解决这个问题。理想情况下,容器中的应用程序应该是无状态的,以便能够多次部署。该容器的每个实例都有不同的端口号,最终由主机系统决定。我想docker是构建PAAS系统的工具,而不是PAAS本身。@JP。参见Maestro的链接此类控制器的一个示例是OpenStack,它支持Docker,并且可以通过编程将IP分配给Docker容器。