通常情况下，我首先使用某个名称启动帮助程序服务，然后当我启动真正的服务时，我会将其链接到帮助程序，一切都会好的。这个模型如何适应Marathon和Mesos？至少现在看来，集装箱化是一个集装箱。
我有一个想法首先启动帮助程序服务，在它可以找到的任何主机上，然后向hostname =帮助程序服务的主机名的实际服务添加约束，但这似乎会导致资源提供和这些资源的竞争条件。
我还想过为docker或启动docker容器的执行程序脚本提供“嵌入”或“深层链接”功能。
在我走下这些路径之前，我想知道是否有其他人已经解决了这个问题，或者我是否只是在思考问题。
谢谢！
答案 0 :(得分：26)
这里有多种方法;并且没有一个是完美的，但是由于编排钩子，Docker的未来版本的情况会有所改善。
一种方法是使用良好的旧服务发现和注册。 I.E.，当服务开始时，它将找出其公开可用的地址，并在例如Zookeeper，Etcd，甚至是Redis。由于服务找出其公开可用的地址并非易事（除非您采用某些约定，例如始终映射端口X：X而不是让Docker协助随机端口），您可能希望从外部进行注册。这意味着您的业务流程层（在这种情况下为Mesos）将启动容器，然后找出主机和端口，并将其放入您的服务发现系统中。我对Marathon并不是很熟悉，但你应该可以注册一个钩子。然后，其他容器将只查找服务发现注册表中的端点地址，简单明了。
您还可以查看Skydock，它会自动为Skydns注册容器的DNS名称。但是，它目前是单主机，所以如果你喜欢这个想法，你必须以某种方式扩展它以支持多个主机，也许还有SRV记录。
另一种方法是使用“众所周知的切入点”。这实际上是服务发现的简化情况。这意味着您将确保您的服务始终在预先设置的主机和端口上运行，以便您可以静态使用这些地址。当然，这很糟糕（因为当你想要为测试/暂存目的重现环境时，它会让你的生活更加艰难），但如果你对服务发现一无所知，那么它可能是一个开始。 / p>
您还可以使用Pipework创建跨多个主机的一个（或多个）虚拟网络，并将容器绑定在一起。 Pipework将允许您手动分配IP地址，或通过DHCP自动分配IP地址。不建议采用这种方法，但如果您还想将容器插入现有网络架构（例如VLAN ......），那么这种方法非常适合。
无论您决定使用哪种解决方案，我强烈建议您“假装”您正在使用链接。即而不是硬编码您的应用程序配置以连接到（随机示例）my-postgresql-db:5432，使用环境变量DB_PORT_5432_TCP_ADDR和DB_PORT_5432_TCP_PORT（就好像它是一个链接），并在启动时设置这些变量容器。这样，如果您将容器“折叠”到一个没有服务发现等的简单环境中，您就可以轻松地回退链接。