As others has mentioned earlier, definitely don't use the "mesos-" prefix to name your docker containers since at the time we did the integration docker labels wasn't merged.
Also you'll need to run mesos-slave with --pid=host, bind mount in the docker socket, and also bind mount a host directory into the slave as its work directory so the slave can recover its tasks when it restarts. Tim On Tue, Jun 30, 2015 at 11:11 PM, zhou weitao <[email protected]> wrote: > If I understand right, the root trouble is mesos-slave-in-docker. I know > CoreOS little, do u run mesos-slave on CoreOS as following? > > docker run --rm -it --name mesos-slave --net host > --volume /var/run/docker.sock:/var/run/docker.sock --entrypoint mesos-slave > .... > > or map the CoreOS docker.sock into mesos-slave container to discovery > service better. > > If I said nothing, sorry for my interruption. > > > 2015-06-30 21:10 GMT+08:00 Andras Kerekes <[email protected]> > : > >> Would not using Bamboo to update haproxy config have the same problems I >> described for the Marathon provided script? It would still run in a >> separate container. >> >> >> >> *From:* zhou weitao [mailto:[email protected]] >> *Sent:* Monday, June 29, 2015 10:51 PM >> *To:* [email protected] >> *Subject:* Re: service discovery in Mesos on CoreOS >> >> >> >> >> >> >> >> 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 >> >> >> > >
