mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andras Kerekes <>
Subject RE: service discovery in Mesos on CoreOS
Date Tue, 30 Jun 2015 13:19:54 GMT
How would this be different from using mesos-dns from the app’s perspective? It uses DNS
interface, thus the app should be able to resolve SRV records, right?


So if I insist on that the resolution of the provided dns name (for the service it depends
on) it should be transient to the app, then it should fail once it cannot connect, have (e.g.)
Marathon restart it, and the launch script should look up the service e.g. using James’
proposal. This again sounds less than ideal.


From: haosdent [] 
Sent: Monday, June 29, 2015 11:20 PM
Subject: Re: service discovery in Mesos on CoreOS


Also have another service discovery tool.


On Tue, Jun 30, 2015 at 10:51 AM, zhou weitao <> wrote:



2015-06-30 6:23 GMT+08:00 Andras Kerekes <>:



Is there a preferred way to do service discovery in Mesos via mesos-dns running on CoreOS?
I’m trying to implement a simple app which consists of two docker containers and one of
them (A) depends on the other (B). What I’d like to do is to tell container A to use a fix
dns name (containerB.marathon.mesos in case of mesos-dns) to find the other service. There
are at least 3 different ways I think it can be done, but the 3 I found all have some shortcomings.


1.       Use SRV records to get the port along with the IP. Con: I’d prefer not to build
the logic of handling SRV records into the app, it can be a legacy app that is difficult to

2.       Use haproxy on slaves and connect via a well-known port on localhost. Cons: the Marathon
provided script does not run on CoreOS, also I don’t know how to run haproxy on CoreOS outside
of a docker container. If it is running in a docker container, then how can it dynamically
allocate ports on localhost if a new service is discovered in Marathon/Mesos?

Do you know this repo? . And here our corp one
branched from the above.

3.       Use dedicated port to bind the containers to. Con: I can have only as many instances
of a service as many slaves I have because they bind to the same port.


What other alternatives are there?







Best Regards,

Haosdent Huang

View raw message