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 [mailto:[email protected]] Sent: Monday, June 29, 2015 11:20 PM To: [email protected] Subject: Re: service discovery in Mesos on CoreOS Also have another service discovery tool. https://www.consul.io/ https://github.com/CiscoCloud/mesos-consul On Tue, Jun 30, 2015 at 10:51 AM, zhou weitao <[email protected]> wrote: 2015-06-30 6:23 GMT+08:00 Andras Kerekes <[email protected]>: Hi, 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 modify 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? https://github.com/QubitProducts/bamboo . And here our corp one https://github.com/Dataman-Cloud/bamboo 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? Thanks, Andras -- Best Regards, Haosdent Huang
smime.p7s
Description: S/MIME cryptographic signature
