Service discovery

Mesos-DNS provides service discovery within a DC/OS cluster. It automatically allows applications and services to find each other via DNS. When an application is launched by Marathon, it gets assigned a name using the naming pattern task.scheduler.mesos. In all of my cases here, that means task.marathon. mesos. So, for example, when I want to find out the IP address of my MongoDB service, I can just issue the command $ dig mongo.marathon.mesos And get a result like the following (which I’ve edited for brevity). ;; QUESTION SECTION: ;mongodb.marathon.mesos. IN

A ;; ANSWER SECTION: mongodb.marathon.mesos. 60 IN A 10.32.0.7

I can go on a little further though—I can use the command ( below) which will give me the information on which host the MongoDB service is running at the current time, but to find the port I need to connect to, I have to look at the service locator DNS record: $ dig _mongodb._tcp.marathon.mesos srv ;; ANSWER SECTION: _mongodb._tcp.marathon.mesos. 60 IN SRV 0 0 3412 mongodb-aht54-s2.marathon.mesos.

_mongodb._tcp.marathon.mesos. 60 IN SRV 0 0 3411 mongodb-aht54-s2.marathon.mesos. ;; ADDITIONAL SECTION: mongodb-aht54-s2.marathon.mesos. 60 IN A 10.32.0.7

Another possibility is to use Named VIPs which offer some benefits over Mesos-DNS (such as no caching or reliance on the SRV record). These are name/port pairs given to an application as part of its packaging—take a look at https://dcos.io/docs/1.8/usage/tutorials/

dcos-101/service-discovery which actually recommends their use over Mesos-DNS as the default service discovery method.