This solution works when the app is being launched. But if the dependency goes down and re-launches at other coordinates, the app depending on it will break, unless it has the knowledge of how to look the dependency up via SRV which I wanted to avoid. This could be solved by running haproxy inside the docker container of the apps, but that would be a really bad practice I think.
From: James DeFelice [mailto:[email protected]] Sent: Monday, June 29, 2015 10:06 PM To: [email protected] Subject: Re: service discovery in Mesos on CoreOS Can you go with option 1, using the http api of mesos-dns to pull a json srv-ish record, parse it with jq, and configure your app accordingly? On Jun 29, 2015 3:24 PM, "Andras Kerekes" <[email protected]> wrote: 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? 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
smime.p7s
Description: S/MIME cryptographic signature
