Toy go app that queries SRV records, generates environment variables and injects them into an exec'd command line:
https://github.com/jdef/srv2env If you wanted template support you could pair this with confd and use the env var backend. If you're running tasks on marathon, when they die there is a possibility that upon being respawned the port # may change (unless you're specifying host ports statically). This toy app doesn't deal with that. On Mon, Jun 29, 2015 at 10:21 PM, Joao Ribeiro <[email protected]> wrote: > Hi, > > I am also facing similar problems with service discovery and load > balancing. It would be great if mesos-dns could resolve > _task._protocol.framework.domain queries to round-robin IP:PORT > combinations. I am not an expert in DNS protocols and probably this > functionality would breach it but even so it would help a lot. If for some > reason the community would prefer this behaviour out of the core > implementation of mesos-dns, we could solve it by implementing ways to > extend it with plugins. This way we could extend mesos-dns to work with > other frameworks and have extra functionalities such as implementing > different load-balancing patterns. > > What do you think of it? I haven’t done anything in GO but would be > willing to contribute to this if you all agree. > > > On 30 Jun 2015, at 03:06, James DeFelice <[email protected]> wrote: > > 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 >> > > -- James DeFelice 585.241.9488 (voice) 650.649.6071 (fax)
