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