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