链接的Docker容器与Mesos /马拉松 [英] Linked Docker Containers with Mesos/Marathon

问题描述

迄今为止，我已经取得了巨大的成功，使用Mesos，Marathon和Docker来管理一系列服务器，以及我所在的容器。然而，我现在想要进一步，开始做一些事情，例如将haproxy容器自动链接到启动的每个主要Docker服务，或者提供其他基于守护进程和集装箱化的服务，这些服务仅链接到单个父容器。

通常我先用一些名字启动帮手服务，然后当我开始真正的服务时，我会链接到帮手，一切都会精细。这个模型怎么适合马拉松和梅索斯呢？至少现在看来，集装箱化是假定一个容器。

我有一个想法，首先要启动帮助服务，在任何可以找到的主机上，然后添加一个对hostname = helper服务的主机名的实际服务的约束，但这似乎会导致这些资源的资源提供和竞争条件的问题。

还想到向docker提供嵌入或深层链接功能，或者向启动Docker容器的执行者脚本提供。

这些路径，我想知道别人是否已经解决了这个问题，或者如果我只是可怕的思考的东西。

谢谢！

解决方案

你在未知的领域漫游！ ☺

这里有多种方法;而且没有一个是完美的，但是由于编排钩子，Docker的未来版本的情况会有所改善。

一种方法是使用良好的旧服务发现和注册。 I.E.，当服务开始时，它将确定其公开可用的地址，并在例如Zookeeper，Etcd，甚至Redis。由于服务可以找出其公开的地址（除非您采用某些约定，例如始终映射端口X：X而不是让Docker分配随机端口），这不是一件容易的事情，您可能需要从外部进行注册。这意味着您的业务流程层（Mesos在这种情况下）将启动容器，然后找出主机和端口，并将其放在您的服务发现系统中。我对Marathon并不十分熟悉，但应该可以注册一个钩子。然后，其他容器将只是查找服务发现注册表中的端点地址，简单而简单。

您还可以查看 Skydock ，它会自动向Skydns注册容器的DNS名称。但是，它目前是单主机，所以如果你喜欢这个想法，你将不得不扩展它以支持多个主机，也可能是SRV记录。

另一种方法是使用知名切入点。这实际上是服务发现的简化情况。这意味着您将确保您的服务将始终运行在预设的主机和端口上，以便您可以静态使用这些地址。当然，这是坏的（因为当你想要重现环境进行测试/分期的目的），但是如果你对服务发现没有任何线索，那么这可能是一个开始。 / p>

您还可以使用 Pipework 创建一个（或多个）虚拟网络跨越多个主机，并将您的容器绑定在一起。管道工作将让您手动分配IP地址，或通过DHCP自动分配IP地址。但是，不建议使用这种方法，但如果您还想将容器插入现有的网络架构（例如VLAN）...，则非常适合。

否决定使用哪种解决方案，我强烈建议您假装使用链接。即而不是硬编码您的应用程序配置来连接（随机示例） my-postgresql-db：5432 ，使用环境变量 DB_PORT_5432_TCP_ADDR 和 DB_PORT_5432_TCP_PORT （好像是一个链接），并在启动容器时设置这些变量。这样，如果您将容器折叠到一个更简单的环境中，无需服务发现等，您就可以轻松地在链接上轻松回退。

I'm having great success so far using Mesos, Marathon, and Docker to manage a fleet of servers, and the containers I'm placing on them. However, I'd now like to go a bit further and start doing things like automatically linking an haproxy container to each main docker service that starts, or provide other daemon based and containerized services that are linked and only available to the single parent container.

Normally, I'd start up the helper service first with some name, then when I started the real service, I'd link it to the helper and everything would be fine. How does this model fit in to Marathon and Mesos though? It seems for now at least that the containerization assumes a single container.

I had one idea to start the helper service first, on whatever host it could find, then add a constraint to the real service that the hostname = helper service's hostname, but that seems like it'd cause issues with resource offers and race conditions for those resources.

I've also thought to provide an "embed", or "deep-link" functionality to docker, or to the executor scripts that start the docker containers.

Before I head down any of these paths, I wanted to find out if someone else had solved this problem, or if I was just horribly over thinking things.

Thanks!

解决方案

you're wandering in uncharted territory! ☺

There are multiple approaches here; and none of them is perfect, but the situation will improve in future versions of Docker, thanks to orchestration hooks.

One way is to use good old service discovery and registration. I.E., when a service starts, it will figure out its publicly available address, and register itself in e.g. Zookeeper, Etcd, or even Redis. Since it's not trivial for a service to figure out its publicly available address (unless you adopt some conventions, e.g. always mapping port X:X instead of letting Docker assing random ports), you might want to do the registration from outside. That means that your orchestration layer (Mesos in that case) would start the container, then figure out the host and port, and put that in your service discovery system. I'm not extremely familiar with Marathon, but you should be able to register a hook for that. Then, other containers will just look up the endpoint address in the service discovery registry, plain and simple.

You could also look at Skydock, which automatically registers DNS names for your containers with Skydns. However, it's currently single-host, so if you like that idea, you'll have to extend it somehow to support multiple hosts, and maybe SRV records.

Another approach is to use "well-known entry points". This is actually is simplified case of service discovery. It means that you will make sure that your services will always run on pre-set hosts and ports, so that you can use those addresses statically. Of course, this is bad (because it will make your life harder when you will want to reproduce the environment for testing/staging purposes), but if you have no clue at all about service discovery, well, it could be a start.

You could also use Pipework to create one (or multiple) virtual network spanning across multiple hosts, and binding your containers together. Pipework will let you assign IP addresses manually, or automatically through DHCP. This approach is not recommended, though, but it's a good fit if you also want to plug your containers into an existing network architecture (e.g. VLANs...).

No matter which solution you decide to use, I highly recommend to "pretend" that you're using links. I.e. instead of hard-coding your app configuration to connect to (random example) my-postgresql-db:5432, use environment variables DB_PORT_5432_TCP_ADDR and DB_PORT_5432_TCP_PORT (as if it were a link), and set those variables when starting the container. That way, if you "fold down" your containers into a simpler environment without service discovery etc., you can easily fallback on links without efforts.

这篇关于链接的Docker容器与Mesos /马拉松的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！