Re: fyi: mesos-dns is not registering all ip addresses
+Jason Kölker
On Mon, Jul 27, 2020 at 8:03 AM Alex Evonosky
wrote:
> Thank you Marc for the clarification.
>
>
>
> On Mon, Jul 27, 2020 at 8:50 AM Marc Roos
> wrote:
>
>>
>> Hi Alex,
>>
>> My config.json is quite similar, but having "IPSources": ["netinfo",
>> "mesos", "host"]
>>
>> You will only run into this issue when you have multihomed tasks, having
>> two or more network adapters, eth0, eth1 etc
>>
>>
>>
>>
>> -Original Message-
>> From: Alex Evonosky [mailto:alex.evono...@gmail.com]
>> Sent: maandag 27 juli 2020 14:36
>> To: user@mesos.apache.org
>> Subject: Re: fyi: mesos-dns is not registering all ip addresses
>>
>> thank you.
>>
>> We have been running mesos-dns for years now without any issues. The
>> docker apps spin up on marathon and automatically gets picked up by
>> mesos-dns...
>>
>> This is our config.json:
>>
>>
>> {
>> "zk": "zk://10.10.10.51:2181,10.10.10.52:2181,10.10.10.53:2181/mesos",
>> "masters": ["10.10.10.51:5050", "10.10.10.52:5050",
>> "10.10.10.53:5050"],
>> "refreshSeconds": 3,
>> "ttl": 3,
>> "domain": "mesos",
>> "port": 53,
>> "resolvers": ["10.10.10.88", "10.10.10.86"],
>> "timeout": 3,
>> "httpon": true,
>> "dnson": true,
>> "httpport": 8123,
>> "externalon": true,
>> "listener": "0.0.0.0",
>> "SOAMname": "ns1.mesos",
>> "SOARname": "root.ns1.mesos",
>> "SOARefresh": 5,
>> "SOARetry": 600,
>> "SOAExpire": 86400,
>> "SOAMinttl": 5,
>> "IPSources":["mesos", "host"]
>> }
>>
>>
>>
>>
>> we just have our main DNS resolvers have a zone "mesos.marathon" and
>> forwards the request to this cluster...
>>
>>
>>
>> On Mon, Jul 27, 2020 at 3:56 AM Marc Roos
>> wrote:
>>
>>
>>
>>
>> I am not sure if mesos-dns is discontinued. But for the ones
>> still
>> using
>> it, in some cases it does not register all tasks ip addresses.
>>
>> The default[2] works, but if you have this setup[1] it will only
>> register one ip address 192.168.122.140 and not the 2nd. I filed
>> issue a
>> year ago or so[3]
>>
>>
>>
>> [3]
>> https://github.com/mesosphere/mesos-dns/issues/54145
>> https://issues.apache.org/jira/browse/MESOS-10164
>>
>> [1]
>> "network_infos": [
>> {
>> "ip_addresses": [
>> {
>> "protocol": "IPv4",
>> "ip_address": "192.168.122.140"
>> }
>> ]
>> },
>> {
>> "ip_addresses": [
>> {
>> "protocol": "IPv4",
>> "ip_address": "192.168.10.17"
>> }
>> ],
>> }
>> ]
>>
>>
>> [2]
>> "network_infos": [
>> {
>> "ip_addresses": [
>> {
>> "protocol": "IPv4",
>> "ip_address": "12.0.1.2"
>> },
>> {
>> "protocol": "IPv6",
>> "ip_address": "fd01:b::1:8000:2"
>> }
>> ],
>> }
>> ]
>>
>>
>>
>>
>>
>>
Re: fyi: mesos-dns is not registering all ip addresses
Thank you Marc for the clarification.
On Mon, Jul 27, 2020 at 8:50 AM Marc Roos wrote:
>
> Hi Alex,
>
> My config.json is quite similar, but having "IPSources": ["netinfo",
> "mesos", "host"]
>
> You will only run into this issue when you have multihomed tasks, having
> two or more network adapters, eth0, eth1 etc
>
>
>
>
> -Original Message-
> From: Alex Evonosky [mailto:alex.evono...@gmail.com]
> Sent: maandag 27 juli 2020 14:36
> To: user@mesos.apache.org
> Subject: Re: fyi: mesos-dns is not registering all ip addresses
>
> thank you.
>
> We have been running mesos-dns for years now without any issues. The
> docker apps spin up on marathon and automatically gets picked up by
> mesos-dns...
>
> This is our config.json:
>
>
> {
> "zk": "zk://10.10.10.51:2181,10.10.10.52:2181,10.10.10.53:2181/mesos",
> "masters": ["10.10.10.51:5050", "10.10.10.52:5050",
> "10.10.10.53:5050"],
> "refreshSeconds": 3,
> "ttl": 3,
> "domain": "mesos",
> "port": 53,
> "resolvers": ["10.10.10.88", "10.10.10.86"],
> "timeout": 3,
> "httpon": true,
> "dnson": true,
> "httpport": 8123,
> "externalon": true,
> "listener": "0.0.0.0",
> "SOAMname": "ns1.mesos",
> "SOARname": "root.ns1.mesos",
> "SOARefresh": 5,
> "SOARetry": 600,
> "SOAExpire": 86400,
> "SOAMinttl": 5,
> "IPSources":["mesos", "host"]
> }
>
>
>
>
> we just have our main DNS resolvers have a zone "mesos.marathon" and
> forwards the request to this cluster...
>
>
>
> On Mon, Jul 27, 2020 at 3:56 AM Marc Roos
> wrote:
>
>
>
>
> I am not sure if mesos-dns is discontinued. But for the ones still
> using
> it, in some cases it does not register all tasks ip addresses.
>
> The default[2] works, but if you have this setup[1] it will only
> register one ip address 192.168.122.140 and not the 2nd. I filed
> issue a
> year ago or so[3]
>
>
>
> [3]
> https://github.com/mesosphere/mesos-dns/issues/54145
> https://issues.apache.org/jira/browse/MESOS-10164
>
> [1]
> "network_infos": [
> {
> "ip_addresses": [
> {
> "protocol": "IPv4",
> "ip_address": "192.168.122.140"
> }
> ]
> },
> {
> "ip_addresses": [
> {
> "protocol": "IPv4",
> "ip_address": "192.168.10.17"
> }
> ],
> }
> ]
>
>
> [2]
> "network_infos": [
> {
> "ip_addresses": [
> {
> "protocol": "IPv4",
> "ip_address": "12.0.1.2"
> },
> {
> "protocol": "IPv6",
> "ip_address": "fd01:b::1:8000:2"
> }
> ],
> }
> ]
>
>
>
>
>
>
RE: fyi: mesos-dns is not registering all ip addresses
Hi Alex,
My config.json is quite similar, but having "IPSources": ["netinfo",
"mesos", "host"]
You will only run into this issue when you have multihomed tasks, having
two or more network adapters, eth0, eth1 etc
-Original Message-
From: Alex Evonosky [mailto:alex.evono...@gmail.com]
Sent: maandag 27 juli 2020 14:36
To: user@mesos.apache.org
Subject: Re: fyi: mesos-dns is not registering all ip addresses
thank you.
We have been running mesos-dns for years now without any issues. The
docker apps spin up on marathon and automatically gets picked up by
mesos-dns...
This is our config.json:
{
"zk": "zk://10.10.10.51:2181,10.10.10.52:2181,10.10.10.53:2181/mesos",
"masters": ["10.10.10.51:5050", "10.10.10.52:5050",
"10.10.10.53:5050"],
"refreshSeconds": 3,
"ttl": 3,
"domain": "mesos",
"port": 53,
"resolvers": ["10.10.10.88", "10.10.10.86"],
"timeout": 3,
"httpon": true,
"dnson": true,
"httpport": 8123,
"externalon": true,
"listener": "0.0.0.0",
"SOAMname": "ns1.mesos",
"SOARname": "root.ns1.mesos",
"SOARefresh": 5,
"SOARetry": 600,
"SOAExpire": 86400,
"SOAMinttl": 5,
"IPSources":["mesos", "host"]
}
we just have our main DNS resolvers have a zone "mesos.marathon" and
forwards the request to this cluster...
On Mon, Jul 27, 2020 at 3:56 AM Marc Roos
wrote:
I am not sure if mesos-dns is discontinued. But for the ones still
using
it, in some cases it does not register all tasks ip addresses.
The default[2] works, but if you have this setup[1] it will only
register one ip address 192.168.122.140 and not the 2nd. I filed
issue a
year ago or so[3]
[3]
https://github.com/mesosphere/mesos-dns/issues/54145
https://issues.apache.org/jira/browse/MESOS-10164
[1]
"network_infos": [
{
"ip_addresses": [
{
"protocol": "IPv4",
"ip_address": "192.168.122.140"
}
]
},
{
"ip_addresses": [
{
"protocol": "IPv4",
"ip_address": "192.168.10.17"
}
],
}
]
[2]
"network_infos": [
{
"ip_addresses": [
{
"protocol": "IPv4",
"ip_address": "12.0.1.2"
},
{
"protocol": "IPv6",
"ip_address": "fd01:b::1:8000:2"
}
],
}
]
Re: fyi: mesos-dns is not registering all ip addresses
thank you.
We have been running mesos-dns for years now without any issues. The
docker apps spin up on marathon and automatically gets picked up by
mesos-dns...
This is our config.json:
{
"zk": "zk://10.10.10.51:2181,10.10.10.52:2181,10.10.10.53:2181/mesos",
"masters": ["10.10.10.51:5050", "10.10.10.52:5050", "10.10.10.53:5050"],
"refreshSeconds": 3,
"ttl": 3,
"domain": "mesos",
"port": 53,
"resolvers": ["10.10.10.88", "10.10.10.86"],
"timeout": 3,
"httpon": true,
"dnson": true,
"httpport": 8123,
"externalon": true,
"listener": "0.0.0.0",
"SOAMname": "ns1.mesos",
"SOARname": "root.ns1.mesos",
"SOARefresh": 5,
"SOARetry": 600,
"SOAExpire": 86400,
"SOAMinttl": 5,
"IPSources":["mesos", "host"]
}
we just have our main DNS resolvers have a zone "mesos.marathon" and
forwards the request to this cluster...
On Mon, Jul 27, 2020 at 3:56 AM Marc Roos wrote:
>
>
> I am not sure if mesos-dns is discontinued. But for the ones still using
> it, in some cases it does not register all tasks ip addresses.
>
> The default[2] works, but if you have this setup[1] it will only
> register one ip address 192.168.122.140 and not the 2nd. I filed issue a
> year ago or so[3]
>
>
>
> [3]
> https://github.com/mesosphere/mesos-dns/issues/54145
> https://issues.apache.org/jira/browse/MESOS-10164
>
> [1]
> "network_infos": [
> {
> "ip_addresses": [
> {
> "protocol": "IPv4",
> "ip_address": "192.168.122.140"
> }
> ]
> },
> {
> "ip_addresses": [
> {
> "protocol": "IPv4",
> "ip_address": "192.168.10.17"
> }
> ],
> }
> ]
>
>
> [2]
> "network_infos": [
> {
> "ip_addresses": [
> {
> "protocol": "IPv4",
> "ip_address": "12.0.1.2"
> },
> {
> "protocol": "IPv6",
> "ip_address": "fd01:b::1:8000:2"
> }
> ],
> }
> ]
>
>
>
fyi: mesos-dns is not registering all ip addresses
I am not sure if mesos-dns is discontinued. But for the ones still using
it, in some cases it does not register all tasks ip addresses.
The default[2] works, but if you have this setup[1] it will only
register one ip address 192.168.122.140 and not the 2nd. I filed issue a
year ago or so[3]
[3]
https://github.com/mesosphere/mesos-dns/issues/54145
https://issues.apache.org/jira/browse/MESOS-10164
[1]
"network_infos": [
{
"ip_addresses": [
{
"protocol": "IPv4",
"ip_address": "192.168.122.140"
}
]
},
{
"ip_addresses": [
{
"protocol": "IPv4",
"ip_address": "192.168.10.17"
}
],
}
]
[2]
"network_infos": [
{
"ip_addresses": [
{
"protocol": "IPv4",
"ip_address": "12.0.1.2"
},
{
"protocol": "IPv6",
"ip_address": "fd01:b::1:8000:2"
}
],
}
]
Task with 2 cni networks, only ip of last network shown in mesos-dns?
Any one else having this also?
Have launched a task like this
"networks": [
{ "mode": "container", "name": "cni-apps" },
{ "mode": "container", "name": "cni-apps-public", "labels":
{"CNI_ARGS": "IP=x.x.x.x"} }
],
dig +short only shows me the ip address of the last network.
curl
http://192.168.10.151:5050/tasks?task_id=sendmail.instance-257020f4-b574-11e9-bdb3-0050563001a1._app.7
| jq .
Shows both ip addresses
using v0.7.0-rc2
RE: Mesos 1.7 to 1.8 upgrade, mesos-dns 0.6.0 not getting task info
Got this issue, fixed with v0.7.0-rc2
Failed to fetch state.json from leader. Error: invalid character 'N'
after top-level valu
https://github.com/mesosphere/mesos-dns/issues/538
-Original Message-
From: Marc Roos
Sent: donderdag 1 augustus 2019 22:15
To: user
Subject: RE: Mesos 1.7 to 1.8 upgrade, mesos-dns 0.6.0 not getting task
info
Looks like marathon does not have the information. Anyone experienced
something similar?
[@log]# curl http://192.168.10.151:8123/v1/hosts/server.marathon.mesos
[
{
"host": "",
"ip": ""
}
-Original Message-
Subject: Mesos 1.7 to 1.8 upgrade, mesos-dns 0.6.0 not getting task info
Mesos-dns does not get any updates, nothing resolves, anything changed
between mesos 1.7 and 1.8 that requires reconfig of mesos-dns?
RE: Mesos 1.7 to 1.8 upgrade, mesos-dns 0.6.0 not getting task info
Looks like marathon does not have the information. Anyone experienced
something similar?
[@log]# curl http://192.168.10.151:8123/v1/hosts/server.marathon.mesos
[
{
"host": "",
"ip": ""
}
-Original Message-
Subject: Mesos 1.7 to 1.8 upgrade, mesos-dns 0.6.0 not getting task info
Mesos-dns does not get any updates, nothing resolves, anything changed
between mesos 1.7 and 1.8 that requires reconfig of mesos-dns?
Mesos 1.7 to 1.8 upgrade, mesos-dns 0.6.0 not getting task info
Mesos-dns does not get any updates, nothing resolves, anything changed between mesos 1.7 and 1.8 that requires reconfig of mesos-dns?
Re: Mesos-dns srv weight
Please seek support through the mesos DNS channels:
https://github.com/mesosphere/mesos-dns#contact
On Fri, Jul 26, 2019 at 9:50 AM Marc Roos wrote:
>
> Is it possible to configure a task with srv record weight?
>
>
> [@ mesos-cni]# dig +short @192.168.10.151 _webchat._tcp.marathon.mesos
> SRV
> 0 0 8181 webchat-jygxm-s1.marathon.mesos.
> 0 0 8181 webchat-h3q8o-s1.marathon.mesos.
>
>
> {
> "id": "/webchat",
> "user": "nobody",
> "cpus": 1,
> "mem": 256,
> "disk": 0,
> "instances": 1,
> "acceptedResourceRoles": ["*"],
> "upgradeStrategy": { "minimumHealthCapacity": 0,
> "maximumOverCapacity": 0 },
> "constraints": [["hostname","CLUSTER","c04.local"]],
> "backoffSeconds": 10,
> "env": { "TOMCAT_HTTP_PORT": "$PORT0" },
> "networks": [
> { "mode": "container", "name": "cni-apps" }
> ],
> "container": {
> "type": "MESOS",
> "docker": {
> "image": "webchat:4.2.0",
> "credential": null,
> "forcePullImage": true
> },
> "portMappings": [
> { "containerPort": 8181, "protocol": "tcp", "name": "http"}
> ]
> },
> "labels": {
> "HAPROXY_GROUP": "webchat",
> "HAPROXY_0_BACKEND_HTTP_HEALTHCHECK_OPTIONS": "n httpchk HEAD
> /webchat/ HTTP/1.1\r\nHost:localhost"
> },
> "healthChecks": [
> {
> "gracePeriodSeconds": 300,
> "intervalSeconds": 30,
> "timeoutSeconds": 5,
> "maxConsecutiveFailures": 3,
> "portIndex": 0,
> "path": "/webchat/",
> "protocol": "MESOS_HTTP"
>
> }
> ]
> }
>
>
>
Mesos-dns srv weight
Is it possible to configure a task with srv record weight?
[@ mesos-cni]# dig +short @192.168.10.151 _webchat._tcp.marathon.mesos
SRV
0 0 8181 webchat-jygxm-s1.marathon.mesos.
0 0 8181 webchat-h3q8o-s1.marathon.mesos.
{
"id": "/webchat",
"user": "nobody",
"cpus": 1,
"mem": 256,
"disk": 0,
"instances": 1,
"acceptedResourceRoles": ["*"],
"upgradeStrategy": { "minimumHealthCapacity": 0,
"maximumOverCapacity": 0 },
"constraints": [["hostname","CLUSTER","c04.local"]],
"backoffSeconds": 10,
"env": { "TOMCAT_HTTP_PORT": "$PORT0" },
"networks": [
{ "mode": "container", "name": "cni-apps" }
],
"container": {
"type": "MESOS",
"docker": {
"image": "webchat:4.2.0",
"credential": null,
"forcePullImage": true
},
"portMappings": [
{ "containerPort": 8181, "protocol": "tcp", "name": "http"}
]
},
"labels": {
"HAPROXY_GROUP": "webchat",
"HAPROXY_0_BACKEND_HTTP_HEALTHCHECK_OPTIONS": "n httpchk HEAD
/webchat/ HTTP/1.1\r\nHost:localhost"
},
"healthChecks": [
{
"gracePeriodSeconds": 300,
"intervalSeconds": 30,
"timeoutSeconds": 5,
"maxConsecutiveFailures": 3,
"portIndex": 0,
"path": "/webchat/",
"protocol": "MESOS_HTTP"
}
]
}
Re: Mesos-DNS Failed to connect to...
shakeel Dig command are perfectly working, i see the correct address on which i have mesos-dns running Unfortunately in the openstack environment where i am working there is not a DNS. And this miss it's causing me a lot a issues also for other stuff. 2016-04-14 15:22 GMT+02:00 shakeel <shakeel.suf...@motortrak.com>: > Hi, > > Once you have mesos-dns running from marathon, test that it's working > properly with dig. > > (You migth want to add you main dns servers as resolvers within the > mesos-dns config and allow recursion.) > > Otherwise, configure you slaves to use the mesos-dns as their dns servers. > > I created a subdomain on my main dns server for the mesos-dns subdomain > which points to the slave where mesos-dns is running. > > This way when you try to access the mesos-dns url from your browser, you > main dns server will know where to forward the request. > > HTH. > > Kind Regards > Shakeel Suffee > > On 14/04/16 14:06, Chris Baker wrote: > > Also, make sure that the machine you're trying to launch from has > > Mesos-DNS as its DNS server :) > > > > On Thu, Apr 14, 2016 at 3:33 AM Stefano Bianchi <jazzist...@gmail.com > > <mailto:jazzist...@gmail.com>> wrote: > > > > Im correctly running mesos-dns from marathon and it seems to work. > > But when i launch: > > > > http://test.marathon.mesos > > > > (where test is a funning task on marathon) > > > > I get: > > > > curl: (7) Failed connect to test.marathon.mesos:80; Connection > refused > > > > Where am i wrong? > > > > Il 13/apr/2016 17:46, "June Taylor" <j...@umn.edu > > <mailto:j...@umn.edu>> ha scritto: > > > > We are running pyspark against our cluster in coarse-grained > > mode by specifying the --master mesos://host:5050 flag, which > > properly creates one task on each node. > > > > However, if the driver is shut down, it appears that these > > executors become orphaned_tasks, still consuming resources on > > the slave, but no longer being represented in the master's > > understanding of available resources. > > > > Examining the stdout/stderr shows it exited: > > > > Registered executor on node4 > > Starting task 0 > > sh -c 'cd spark-1*; ./bin/spark-class > > org.apache.spark.executor.CoarseGrainedExecutorBackend > > --driver-url > > spark://CoarseGrainedScheduler@128.101.163.200:41563 > > <http://CoarseGrainedScheduler@128.101.163.200:41563> > > --executor-id aa1337b6-43b0-4236-b445-c8ccbfb60506-S2/0 > > --hostname node4 --cores 31 --app-id > > aa1337b6-43b0-4236-b445-c8ccbfb60506-0097' > > Forked command at 117620 > > Command exited with status 1 (pid: 117620) > > > > But, these executors are remaining on all the slaves. > > > > What can we do to clear them out? Stopping mesos-slave and > > removing the full work-dir is successful, but also destroys our > > other tasks. > > > > Thanks, > > June Taylor > > System Administrator, Minnesota Population Center > > University of Minnesota > > > > -- > The information contained in this message is for the intended addressee > only and may contain confidential and/or privileged information. If you are > not the intended addressee, please delete this message and notify the > sender; do not copy or distribute this message or disclose its contents to > anyone. Any views or opinions expressed in this message are those of the > author and do not necessarily represent those of Motortrak Limited or of > any of its associated companies. No reliance may be placed on this message > without written confirmation from an authorised representative of the > company. > > Registered in England 3098391 V.A.T. Registered No. 667463890 >
Re: Mesos-DNS Failed to connect to...
Hi, Once you have mesos-dns running from marathon, test that it's working properly with dig. (You migth want to add you main dns servers as resolvers within the mesos-dns config and allow recursion.) Otherwise, configure you slaves to use the mesos-dns as their dns servers. I created a subdomain on my main dns server for the mesos-dns subdomain which points to the slave where mesos-dns is running. This way when you try to access the mesos-dns url from your browser, you main dns server will know where to forward the request. HTH. Kind Regards Shakeel Suffee On 14/04/16 14:06, Chris Baker wrote: > Also, make sure that the machine you're trying to launch from has > Mesos-DNS as its DNS server :) > > On Thu, Apr 14, 2016 at 3:33 AM Stefano Bianchi <jazzist...@gmail.com > <mailto:jazzist...@gmail.com>> wrote: > > Im correctly running mesos-dns from marathon and it seems to work. > But when i launch: > > http://test.marathon.mesos > > (where test is a funning task on marathon) > > I get: > > curl: (7) Failed connect to test.marathon.mesos:80; Connection refused > > Where am i wrong? > > Il 13/apr/2016 17:46, "June Taylor" <j...@umn.edu > <mailto:j...@umn.edu>> ha scritto: > > We are running pyspark against our cluster in coarse-grained > mode by specifying the --master mesos://host:5050 flag, which > properly creates one task on each node. > > However, if the driver is shut down, it appears that these > executors become orphaned_tasks, still consuming resources on > the slave, but no longer being represented in the master's > understanding of available resources. > > Examining the stdout/stderr shows it exited: > > Registered executor on node4 > Starting task 0 > sh -c 'cd spark-1*; ./bin/spark-class > org.apache.spark.executor.CoarseGrainedExecutorBackend > --driver-url > spark://CoarseGrainedScheduler@128.101.163.200:41563 > <http://CoarseGrainedScheduler@128.101.163.200:41563> > --executor-id aa1337b6-43b0-4236-b445-c8ccbfb60506-S2/0 > --hostname node4 --cores 31 --app-id > aa1337b6-43b0-4236-b445-c8ccbfb60506-0097' > Forked command at 117620 > Command exited with status 1 (pid: 117620) > > But, these executors are remaining on all the slaves. > > What can we do to clear them out? Stopping mesos-slave and > removing the full work-dir is successful, but also destroys our > other tasks. > > Thanks, > June Taylor > System Administrator, Minnesota Population Center > University of Minnesota > -- The information contained in this message is for the intended addressee only and may contain confidential and/or privileged information. If you are not the intended addressee, please delete this message and notify the sender; do not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the author and do not necessarily represent those of Motortrak Limited or of any of its associated companies. No reliance may be placed on this message without written confirmation from an authorised representative of the company. Registered in England 3098391 V.A.T. Registered No. 667463890
Re: Mesos-DNS Failed to connect to...
Also, make sure that the machine you're trying to launch from has Mesos-DNS as its DNS server :) On Thu, Apr 14, 2016 at 3:33 AM Stefano Bianchi <jazzist...@gmail.com> wrote: > Im correctly running mesos-dns from marathon and it seems to work. > But when i launch: > > http://test.marathon.mesos > > (where test is a funning task on marathon) > > I get: > > curl: (7) Failed connect to test.marathon.mesos:80; Connection refused > > Where am i wrong? > Il 13/apr/2016 17:46, "June Taylor" <j...@umn.edu> ha scritto: > >> We are running pyspark against our cluster in coarse-grained mode by >> specifying the --master mesos://host:5050 flag, which properly creates >> one task on each node. >> >> However, if the driver is shut down, it appears that these executors >> become orphaned_tasks, still consuming resources on the slave, but no >> longer being represented in the master's understanding of available >> resources. >> >> Examining the stdout/stderr shows it exited: >> >> Registered executor on node4 >> Starting task 0 >> sh -c 'cd spark-1*; ./bin/spark-class >> org.apache.spark.executor.CoarseGrainedExecutorBackend --driver-url spark:// >> CoarseGrainedScheduler@128.101.163.200:41563 --executor-id >> aa1337b6-43b0-4236-b445-c8ccbfb60506-S2/0 --hostname node4 --cores 31 >> --app-id aa1337b6-43b0-4236-b445-c8ccbfb60506-0097' >> Forked command at 117620 >> Command exited with status 1 (pid: 117620) >> >> But, these executors are remaining on all the slaves. >> >> What can we do to clear them out? Stopping mesos-slave and removing the >> full work-dir is successful, but also destroys our other tasks. >> >> Thanks, >> June Taylor >> System Administrator, Minnesota Population Center >> University of Minnesota >> >
Re: Mesos-DNS Failed to connect to...
Stefano, Try inspecting the DNS directly, for example here is an nslookup query to find the port and slave node that contains a running Docker container started by Marathon, and then you can see the curl command touching on that node and the port specified in the SRV record. I am not sure your expectation of having test.marathon.mesos as a valid DNS A-record is correct. june@cluster:~$ nslookup -type=SRV _tomsflask._tcp.marathon.mesos _tomsflask._tcp.marathon.mesos service = 0 0 31427 tomsflask-5p8ho-s83. marathon.slave.mesos. june@cluster:~$ curl http://tomsflask-5p8ho-s83.marathon.slave.mesos:31427 Hello World from Flask (default) Thanks, June Taylor System Administrator, Minnesota Population Center University of Minnesota On Thu, Apr 14, 2016 at 2:33 AM, Stefano Bianchi <jazzist...@gmail.com> wrote: > Im correctly running mesos-dns from marathon and it seems to work. > But when i launch: > > http://test.marathon.mesos > > (where test is a funning task on marathon) > > I get: > > curl: (7) Failed connect to test.marathon.mesos:80; Connection refused > > Where am i wrong? > Il 13/apr/2016 17:46, "June Taylor" <j...@umn.edu> ha scritto: > >> We are running pyspark against our cluster in coarse-grained mode by >> specifying the --master mesos://host:5050 flag, which properly creates >> one task on each node. >> >> However, if the driver is shut down, it appears that these executors >> become orphaned_tasks, still consuming resources on the slave, but no >> longer being represented in the master's understanding of available >> resources. >> >> Examining the stdout/stderr shows it exited: >> >> Registered executor on node4 >> Starting task 0 >> sh -c 'cd spark-1*; ./bin/spark-class >> org.apache.spark.executor.CoarseGrainedExecutorBackend --driver-url spark:// >> CoarseGrainedScheduler@128.101.163.200:41563 --executor-id >> aa1337b6-43b0-4236-b445-c8ccbfb60506-S2/0 --hostname node4 --cores 31 >> --app-id aa1337b6-43b0-4236-b445-c8ccbfb60506-0097' >> Forked command at 117620 >> Command exited with status 1 (pid: 117620) >> >> But, these executors are remaining on all the slaves. >> >> What can we do to clear them out? Stopping mesos-slave and removing the >> full work-dir is successful, but also destroys our other tasks. >> >> Thanks, >> June Taylor >> System Administrator, Minnesota Population Center >> University of Minnesota >> >
Re: Mesos-DNS Failed to connect to...
https://mesosphere.github.io/mesos-dns/docs/naming.html \-- **Rodrick Brown** / Systems Engineer +1 917 445 6839 / [rodr...@orchardplatform.com](mailto:char...@orchardplatform.com) **Orchard Platform** 101 5th Avenue, 4th Floor, New York, NY 10003 [http://www.orchardplatform.com](http://www.orchardplatform.com/) [Orchard Blog](http://www.orchardplatform.com/blog/) | [Marketplace Lending Meetup](http://www.meetup.com/Peer-to-Peer-Lending-P2P/) On Apr 14 2016, at 3:33 am, Stefano Bianchi jazzist...@gmail.com wrote: > Im correctly running mesos-dns from marathon and it seems to work. But when i launch: > > <http://test.marathon.mesos> > > (where test is a funning task on marathon) > > I get: > > curl: (7) Failed connect to test.marathon.mesos:80; Connection refused > > Where am i wrong? > > Il 13/apr/2016 17:46, "June Taylor" [j...@umn.edu](mailto:j...@umn.edu) ha scritto: > >> We are running pyspark against our cluster in coarse-grained mode by specifying the \--master mesos://host:5050 flag, which properly creates one task on each node. >> >> >> >> However, if the driver is shut down, it appears that these executors become orphaned_tasks, still consuming resources on the slave, but no longer being represented in the master's understanding of available resources. >> >> >> >> Examining the stdout/stderr shows it exited: >> >> >> >> Registered executor on node4 >> >> Starting task 0 >> >> sh -c 'cd spark-1*; ./bin/spark-class org.apache.spark.executor.CoarseGrainedExecutorBackend --driver-url spark://[C oarseGrainedScheduler@128.101.163.200:41563](http://CoarseGrainedScheduler@128 .101.163.200:41563) \--executor-id aa1337b6-43b0-4236-b445-c8ccbfb60506-S2/0 --hostname node4 --cores 31 --app-id aa1337b6-43b0-4236-b445-c8ccbfb60506-0097' >> >> Forked command at 117620 >> >> Command exited with status 1 (pid: 117620) >> >> >> >> But, these executors are remaining on all the slaves. >> >> >> >> What can we do to clear them out? Stopping mesos-slave and removing the full work-dir is successful, but also destroys our other tasks. >> >> >> >> Thanks, >> >> June Taylor >> >> System Administrator, Minnesota Population Center >> >> University of Minnesota -- *NOTICE TO RECIPIENTS*: This communication is confidential and intended for the use of the addressee only. If you are not an intended recipient of this communication, please delete it immediately and notify the sender by return email. Unauthorized reading, dissemination, distribution or copying of this communication is prohibited. This communication does not constitute an offer to sell or a solicitation of an indication of interest to purchase any loan, security or any other financial product or instrument, nor is it an offer to sell or a solicitation of an indication of interest to purchase any products or services to any persons who are prohibited from receiving such information under applicable law. The contents of this communication may not be accurate or complete and are subject to change without notice. As such, Orchard App, Inc. (including its subsidiaries and affiliates, "Orchard") makes no representation regarding the accuracy or completeness of the information contained herein. The intended recipient is advised to consult its own professional advisors, including those specializing in legal, tax and accounting matters. Orchard does not provide legal, tax or accounting advice.
Mesos-DNS Failed to connect to...
Im correctly running mesos-dns from marathon and it seems to work. But when i launch: http://test.marathon.mesos (where test is a funning task on marathon) I get: curl: (7) Failed connect to test.marathon.mesos:80; Connection refused Where am i wrong? Il 13/apr/2016 17:46, "June Taylor" <j...@umn.edu> ha scritto: > We are running pyspark against our cluster in coarse-grained mode by > specifying the --master mesos://host:5050 flag, which properly creates > one task on each node. > > However, if the driver is shut down, it appears that these executors > become orphaned_tasks, still consuming resources on the slave, but no > longer being represented in the master's understanding of available > resources. > > Examining the stdout/stderr shows it exited: > > Registered executor on node4 > Starting task 0 > sh -c 'cd spark-1*; ./bin/spark-class > org.apache.spark.executor.CoarseGrainedExecutorBackend --driver-url spark:// > CoarseGrainedScheduler@128.101.163.200:41563 --executor-id > aa1337b6-43b0-4236-b445-c8ccbfb60506-S2/0 --hostname node4 --cores 31 > --app-id aa1337b6-43b0-4236-b445-c8ccbfb60506-0097' > Forked command at 117620 > Command exited with status 1 (pid: 117620) > > But, these executors are remaining on all the slaves. > > What can we do to clear them out? Stopping mesos-slave and removing the > full work-dir is successful, but also destroys our other tasks. > > Thanks, > June Taylor > System Administrator, Minnesota Population Center > University of Minnesota >
Re: resolving hosts with mesos-dns not working with "/" in the appid
According to the docs, it is possible: Mesos-DNS follows RFC 952 for name formatting. All fields used to construct hostnames for A records and service names for SRV records must be up to 24 characters and drawn from the alphabet (A-Z), digits (0-9) and minus sign (-). No distinction is made between upper and lower case. If the task name does not comply with these constraints, Mesos-DNS will trim it, remove all invalid characters, and replace period (.) with sign (-) for task names. However, it is a bit dodgy, specially if your app id is longer than 24 characters. It sometimes work, sometimes does not. I think your record will go along the lines of: mesosspark-shuffle-service.marathon.mesos and so on. Be careful about the 24 character limit. Depending on where the invalid characters happen in the string, it may render the whole record unavailable (mesos-dns will not be able to return it). Kind regards, Radek Gruchalski ra...@gruchalski.com (mailto:ra...@gruchalski.com) (mailto:ra...@gruchalski.com) de.linkedin.com/in/radgruchalski/ (http://de.linkedin.com/in/radgruchalski/) Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. On Tuesday, 17 November 2015 at 20:40, Rodrick Brown wrote: > Is it possible to resolve app-ids with / in them when using mesos-dns? > > > I have apps defined like the following: > > /kafkadirectconsumer/es-services > /mesos/spark-shuffle-service > > > however trying to resolve any appID with a “/“ in the name returns NXDOMAIN > In the above case I thought the following should work > > $ dig mess_spark-shuffle-service.marathon.mesos > > I don’t get the IP of those service. > > > -- > > > > > Rodrick Brown / DevOPs Engineer > +1 917 445 6839 / rodr...@orchardplatform.com > (mailto:char...@orchardplatform.com) > > > Orchard Platform > 101 5th Avenue, 4th Floor, New York, NY 10003 > http://www.orchardplatform.com (http://www.orchardplatform.com/) > > > Orchard Blog (http://www.orchardplatform.com/blog/) | Marketplace Lending > Meetup (http://www.meetup.com/Peer-to-Peer-Lending-P2P/) > > > > > > > > > > > > > > > NOTICE TO RECIPIENTS: This communication is confidential and intended for the > use of the addressee only. If you are not an intended recipient of this > communication, please delete it immediately and notify the sender by return > email. Unauthorized reading, dissemination, distribution or copying of this > communication is prohibited. This communication does not constitute an offer > to sell or a solicitation of an indication of interest to purchase any loan, > security or any other financial product or instrument, nor is it an offer to > sell or a solicitation of an indication of interest to purchase any products > or services to any persons who are prohibited from receiving such information > under applicable law. The contents of this communication may not be accurate > or complete and are subject to change without notice. As such, Orchard App, > Inc. (including its subsidiaries and affiliates, "Orchard") makes no > representation regarding the accuracy or completeness of the information > contained herein. The intended recipient is advised to consult its own > professional advisors, including those specializing in legal, tax and > accounting matters. Orchard does not provide legal, tax or accounting advice. >
Re: resolving hosts with mesos-dns not working with "/" in the appid
same here 2015-11-18 3:54 GMT+08:00 Vinod Kone <vinodk...@gmail.com>: > I think this is a question better suited for the mesos-dns or mesosphere > mailing list. > > On Tue, Nov 17, 2015 at 11:40 AM, Rodrick Brown <rodr...@orchard-app.com> > wrote: > >> Is it possible to resolve app-ids with / in them when using mesos-dns? >> >> >> I have apps defined like the following: >> >> /kafkadirectconsumer/es-services >> /mesos/spark-shuffle-service >> >> >> however trying to resolve any appID with a “/“ in the name returns >> NXDOMAIN >> In the above case I thought the following should work >> >> $ dig mess_spark-shuffle-service.marathon.mesos >> >> I don’t get the IP of those service. >> >> >> -- >> >> [image: Orchard Platform] <http://www.orchardplatform.com/> >> >> Rodrick Brown / DevOPs Engineer >> +1 917 445 6839 / rodr...@orchardplatform.com >> <char...@orchardplatform.com> >> >> Orchard Platform >> 101 5th Avenue, 4th Floor, New York, NY 10003 >> http://www.orchardplatform.com >> >> Orchard Blog <http://www.orchardplatform.com/blog/> | Marketplace >> Lending Meetup <http://www.meetup.com/Peer-to-Peer-Lending-P2P/> >> >> >> *NOTICE TO RECIPIENTS*: This communication is confidential and intended >> for the use of the addressee only. If you are not an intended recipient of >> this communication, please delete it immediately and notify the sender >> by return email. Unauthorized reading, dissemination, distribution or >> copying of this communication is prohibited. This communication does not >> constitute >> an offer to sell or a solicitation of an indication of interest to purchase >> any loan, security or any other financial product or instrument, nor is it >> an offer to sell or a solicitation of an indication of interest to purchase >> any products or services to any persons who are prohibited from receiving >> such information under applicable law. The contents of this communication >> may not be accurate or complete and are subject to change without notice. >> As such, Orchard App, Inc. (including its subsidiaries and affiliates, >> "Orchard") makes no representation regarding the accuracy or >> completeness of the information contained herein. The intended recipient is >> advised to consult its own professional advisors, including those >> specializing in legal, tax and accounting matters. Orchard does not >> provide legal, tax or accounting advice. >> > > -- Deshi Xiao Twitter: xds2000 E-mail: xiaods(AT)gmail.com
resolving hosts with mesos-dns not working with "/" in the appid
Is it possible to resolve app-ids with / in them when using mesos-dns? I have apps defined like the following: /kafkadirectconsumer/es-services /mesos/spark-shuffle-service however trying to resolve any appID with a “/“ in the name returns NXDOMAIN In the above case I thought the following should work $ dig mess_spark-shuffle-service.marathon.mesos I don’t get the IP of those service. -- <http://www.orchardplatform.com/> Rodrick Brown / DevOPs Engineer +1 917 445 6839 / rodr...@orchardplatform.com <mailto:char...@orchardplatform.com> Orchard Platform 101 5th Avenue, 4th Floor, New York, NY 10003 http://www.orchardplatform.com <http://www.orchardplatform.com/> Orchard Blog <http://www.orchardplatform.com/blog/> | Marketplace Lending Meetup <http://www.meetup.com/Peer-to-Peer-Lending-P2P/> -- *NOTICE TO RECIPIENTS*: This communication is confidential and intended for the use of the addressee only. If you are not an intended recipient of this communication, please delete it immediately and notify the sender by return email. Unauthorized reading, dissemination, distribution or copying of this communication is prohibited. This communication does not constitute an offer to sell or a solicitation of an indication of interest to purchase any loan, security or any other financial product or instrument, nor is it an offer to sell or a solicitation of an indication of interest to purchase any products or services to any persons who are prohibited from receiving such information under applicable law. The contents of this communication may not be accurate or complete and are subject to change without notice. As such, Orchard App, Inc. (including its subsidiaries and affiliates, "Orchard") makes no representation regarding the accuracy or completeness of the information contained herein. The intended recipient is advised to consult its own professional advisors, including those specializing in legal, tax and accounting matters. Orchard does not provide legal, tax or accounting advice.
Re: resolving hosts with mesos-dns not working with "/" in the appid
I think this is a question better suited for the mesos-dns or mesosphere mailing list. On Tue, Nov 17, 2015 at 11:40 AM, Rodrick Brown <rodr...@orchard-app.com> wrote: > Is it possible to resolve app-ids with / in them when using mesos-dns? > > > I have apps defined like the following: > > /kafkadirectconsumer/es-services > /mesos/spark-shuffle-service > > > however trying to resolve any appID with a “/“ in the name returns > NXDOMAIN > In the above case I thought the following should work > > $ dig mess_spark-shuffle-service.marathon.mesos > > I don’t get the IP of those service. > > > -- > > [image: Orchard Platform] <http://www.orchardplatform.com/> > > Rodrick Brown / DevOPs Engineer > +1 917 445 6839 / rodr...@orchardplatform.com > <char...@orchardplatform.com> > > Orchard Platform > 101 5th Avenue, 4th Floor, New York, NY 10003 > http://www.orchardplatform.com > > Orchard Blog <http://www.orchardplatform.com/blog/> | Marketplace Lending > Meetup <http://www.meetup.com/Peer-to-Peer-Lending-P2P/> > > > *NOTICE TO RECIPIENTS*: This communication is confidential and intended > for the use of the addressee only. If you are not an intended recipient of > this communication, please delete it immediately and notify the sender by > return email. Unauthorized reading, dissemination, distribution or copying > of this communication is prohibited. This communication does not constitute > an offer to sell or a solicitation of an indication of interest to purchase > any loan, security or any other financial product or instrument, nor is it > an offer to sell or a solicitation of an indication of interest to purchase > any products or services to any persons who are prohibited from receiving > such information under applicable law. The contents of this communication > may not be accurate or complete and are subject to change without notice. > As such, Orchard App, Inc. (including its subsidiaries and affiliates, > "Orchard") makes no representation regarding the accuracy or completeness > of the information contained herein. The intended recipient is advised to > consult its own professional advisors, including those specializing in > legal, tax and accounting matters. Orchard does not provide legal, tax or > accounting advice. >
Re: Marathon 0.11.1 - Mesos 0.25 - Mesos-DNS 0.4.0
I used "IPSources": ["host", "netinfo", "mesos"] With the thought that I would preference for the host at this point. When network isolation works in Marathon, then I will likely switch to netinfo. On Mon, Nov 2, 2015 at 7:28 PM, James DeFelice <james.defel...@gmail.com> wrote: > What settings worked for you? We did aim for least surprise. Sounds like > we missed a bit. We're happy to accept suggestions for improvement via gh > issues filed against the mesos-dns repo. > On Oct 29, 2015 7:39 AM, "John Omernik" <j...@omernik.com> wrote: > >> That is good to know, however, I would challenge the group on something >> like this not being bug based on the documentation. When a change in >> mesos-dns, and what fields it looks at is not affected by the mesos-dns >> component, but instead other components in a way that could have serious >> negative impacts on folks who are running this, there should be some >> fanfare there about changes. Also, I would advocate that in mesos-dns the >> default should have been the same as previous releases (which I would >> assume was host ip) as default, then allow people who are aware of the >> underpinnings to make the change. >> >> On Wed, Oct 28, 2015 at 3:02 PM, Grzegorz Graczyk <gregor...@gmail.com> >> wrote: >> >>> It's not a bug, it's a feature - >>> http://mesosphere.github.io/mesos-dns/docs/configuration-parameters.html >>> look >>> at IPSources config >>> >>> śr., 28.10.2015 o 15:59 użytkownik John Omernik <j...@omernik.com> >>> napisał: >>> >>>> If I rolled back mesos-dns to v0.2.0 (on the releases page) then it >>>> pulls the right IP address.. (Mesos-dns version is the easiest of the >>>> three to change) >>>> >>>> John >>>> >>>> On Wed, Oct 28, 2015 at 9:52 AM, John Omernik <j...@omernik.com> wrote: >>>> >>>>> So, the issues that are listed appear to be resolved with marathon >>>>> 0.11.1, and the mesos-dns issue is not listed at all. >>>>> >>>>> Note, I tried mesos-dns 0.3.0 and that has the same problem as 0.4.0. >>>>> >>>>> On Wed, Oct 28, 2015 at 9:46 AM, John Omernik <j...@omernik.com> >>>>> wrote: >>>>> >>>>>> I will check out those issues and report back. >>>>>> >>>>>> On Wed, Oct 28, 2015 at 9:42 AM, craig w <codecr...@gmail.com> wrote: >>>>>> >>>>>>> I've had no issue with the following combination: >>>>>>> >>>>>>> MesosDNS 0.4.0 >>>>>>> Marathon 0.11.0 >>>>>>> Mesos 0.24.1 >>>>>>> >>>>>>> I've been waiting to upgrade to Mesos 0.25.0 because of issues >>>>>>> mentioned in the mesos mailing list regarding Marathon 0.11.x and Mesos >>>>>>> 0.25.0 >>>>>>> >>>>>>> On Wed, Oct 28, 2015 at 10:38 AM, John Omernik <j...@omernik.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hey all - >>>>>>>> >>>>>>>> I am cross posting this because it's a number of moving parts that >>>>>>>> could be at issue here (Mesos, Mesos-dns, and/or Marathon). >>>>>>>> >>>>>>>> Basically: At the version combination in Subject, the IP that is >>>>>>>> registered in mesos-dns for Docker containers running in Marathon is >>>>>>>> the >>>>>>>> internal (container) IP address of the docker (in bridged mode) not the >>>>>>>> nodes. This obviously causes issues. Note this doesn't happen when the >>>>>>>> Marathon application is non-Docker. >>>>>>>> >>>>>>>> I was running Mesos-dns 0.4.0 on a cluster running Mesos 0.24.0 and >>>>>>>> Marathon 0.10.0 and I upgraded to Mesos 0.25.0 and Marathon 0.11.1 and >>>>>>>> noticed this behavior happening. >>>>>>>> >>>>>>>> I thought that was odd because I have another cluster that was >>>>>>>> running Mesos 0.25.0 and Marathon 0.11.1 and it wasn't happening, >>>>>>>> until I >>>>>>>> realized that I hadn't upgraded Mesos-dns lately, I upgraded to >>>>>>>> Mesos-dns >>>>>>>> 0.4.0 and the problem started occurring. >>>>>>>> >>>>>>>> Is there a setting that I need to use the external IP of the >>>>>>>> container? Is this issue known? Is there a workaround? This is pretty >>>>>>>> major >>>>>>>> for Docker running on Marathon and using Mesos-dns for service >>>>>>>> discovery. >>>>>>>> >>>>>>>> John Omernik >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> https://github.com/mindscratch >>>>>>> https://www.google.com/+CraigWickesser >>>>>>> https://twitter.com/mind_scratch >>>>>>> https://twitter.com/craig_links >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "marathon-framework" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to marathon-framework+unsubscr...@googlegroups.com. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "marathon-framework" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to marathon-framework+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >>
Re: Marathon 0.11.1 - Mesos 0.25 - Mesos-DNS 0.4.0
No, it wasn't specified at all. I was using an old config.json, thus I had to add the setting with the host listed first for it to work. Not sure why docker ended up being first in line there. On Tue, Nov 3, 2015 at 2:02 PM, James DeFelice <james.defel...@gmail.com> wrote: > The default value of IPSources doesn't have `docker` listed. As long as > that's not in the list you shouldn't have had a problem, unless some bad > actor was writing the wrong labels into the task. I don't see support for > NetworkInfos (`netinfos`) in marathon yet. Which means that `host` should > have been the fallback. > > Did you, by chance, have `docker` listed in IPSources at any point? > > > On Tue, Nov 3, 2015 at 12:04 PM, John Omernik <j...@omernik.com> wrote: > >> I used >> >> "IPSources": ["host", "netinfo", "mesos"] >> >> >> With the thought that I would preference for the host at this point. When >> network isolation works in Marathon, then I will likely switch to netinfo. >> >> On Mon, Nov 2, 2015 at 7:28 PM, James DeFelice <james.defel...@gmail.com> >> wrote: >> >>> What settings worked for you? We did aim for least surprise. Sounds like >>> we missed a bit. We're happy to accept suggestions for improvement via gh >>> issues filed against the mesos-dns repo. >>> On Oct 29, 2015 7:39 AM, "John Omernik" <j...@omernik.com> wrote: >>> >>>> That is good to know, however, I would challenge the group on something >>>> like this not being bug based on the documentation. When a change in >>>> mesos-dns, and what fields it looks at is not affected by the mesos-dns >>>> component, but instead other components in a way that could have serious >>>> negative impacts on folks who are running this, there should be some >>>> fanfare there about changes. Also, I would advocate that in mesos-dns the >>>> default should have been the same as previous releases (which I would >>>> assume was host ip) as default, then allow people who are aware of the >>>> underpinnings to make the change. >>>> >>>> On Wed, Oct 28, 2015 at 3:02 PM, Grzegorz Graczyk <gregor...@gmail.com> >>>> wrote: >>>> >>>>> It's not a bug, it's a feature - >>>>> http://mesosphere.github.io/mesos-dns/docs/configuration-parameters.html >>>>> look >>>>> at IPSources config >>>>> >>>>> śr., 28.10.2015 o 15:59 użytkownik John Omernik <j...@omernik.com> >>>>> napisał: >>>>> >>>>>> If I rolled back mesos-dns to v0.2.0 (on the releases page) then it >>>>>> pulls the right IP address.. (Mesos-dns version is the easiest of the >>>>>> three to change) >>>>>> >>>>>> John >>>>>> >>>>>> On Wed, Oct 28, 2015 at 9:52 AM, John Omernik <j...@omernik.com> >>>>>> wrote: >>>>>> >>>>>>> So, the issues that are listed appear to be resolved with marathon >>>>>>> 0.11.1, and the mesos-dns issue is not listed at all. >>>>>>> >>>>>>> Note, I tried mesos-dns 0.3.0 and that has the same problem as >>>>>>> 0.4.0. >>>>>>> >>>>>>> On Wed, Oct 28, 2015 at 9:46 AM, John Omernik <j...@omernik.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I will check out those issues and report back. >>>>>>>> >>>>>>>> On Wed, Oct 28, 2015 at 9:42 AM, craig w <codecr...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I've had no issue with the following combination: >>>>>>>>> >>>>>>>>> MesosDNS 0.4.0 >>>>>>>>> Marathon 0.11.0 >>>>>>>>> Mesos 0.24.1 >>>>>>>>> >>>>>>>>> I've been waiting to upgrade to Mesos 0.25.0 because of issues >>>>>>>>> mentioned in the mesos mailing list regarding Marathon 0.11.x and >>>>>>>>> Mesos >>>>>>>>> 0.25.0 >>>>>>>>> >>>>>>>>> On Wed, Oct 28, 2015 at 10:38 AM, John Omernik <j...@omernik.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>
Re: Marathon 0.11.1 - Mesos 0.25 - Mesos-DNS 0.4.0
The default value of IPSources doesn't have `docker` listed. As long as that's not in the list you shouldn't have had a problem, unless some bad actor was writing the wrong labels into the task. I don't see support for NetworkInfos (`netinfos`) in marathon yet. Which means that `host` should have been the fallback. Did you, by chance, have `docker` listed in IPSources at any point? On Tue, Nov 3, 2015 at 12:04 PM, John Omernik <j...@omernik.com> wrote: > I used > > "IPSources": ["host", "netinfo", "mesos"] > > > With the thought that I would preference for the host at this point. When > network isolation works in Marathon, then I will likely switch to netinfo. > > On Mon, Nov 2, 2015 at 7:28 PM, James DeFelice <james.defel...@gmail.com> > wrote: > >> What settings worked for you? We did aim for least surprise. Sounds like >> we missed a bit. We're happy to accept suggestions for improvement via gh >> issues filed against the mesos-dns repo. >> On Oct 29, 2015 7:39 AM, "John Omernik" <j...@omernik.com> wrote: >> >>> That is good to know, however, I would challenge the group on something >>> like this not being bug based on the documentation. When a change in >>> mesos-dns, and what fields it looks at is not affected by the mesos-dns >>> component, but instead other components in a way that could have serious >>> negative impacts on folks who are running this, there should be some >>> fanfare there about changes. Also, I would advocate that in mesos-dns the >>> default should have been the same as previous releases (which I would >>> assume was host ip) as default, then allow people who are aware of the >>> underpinnings to make the change. >>> >>> On Wed, Oct 28, 2015 at 3:02 PM, Grzegorz Graczyk <gregor...@gmail.com> >>> wrote: >>> >>>> It's not a bug, it's a feature - >>>> http://mesosphere.github.io/mesos-dns/docs/configuration-parameters.html >>>> look >>>> at IPSources config >>>> >>>> śr., 28.10.2015 o 15:59 użytkownik John Omernik <j...@omernik.com> >>>> napisał: >>>> >>>>> If I rolled back mesos-dns to v0.2.0 (on the releases page) then it >>>>> pulls the right IP address.. (Mesos-dns version is the easiest of the >>>>> three to change) >>>>> >>>>> John >>>>> >>>>> On Wed, Oct 28, 2015 at 9:52 AM, John Omernik <j...@omernik.com> >>>>> wrote: >>>>> >>>>>> So, the issues that are listed appear to be resolved with marathon >>>>>> 0.11.1, and the mesos-dns issue is not listed at all. >>>>>> >>>>>> Note, I tried mesos-dns 0.3.0 and that has the same problem as 0.4.0. >>>>>> >>>>>> On Wed, Oct 28, 2015 at 9:46 AM, John Omernik <j...@omernik.com> >>>>>> wrote: >>>>>> >>>>>>> I will check out those issues and report back. >>>>>>> >>>>>>> On Wed, Oct 28, 2015 at 9:42 AM, craig w <codecr...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I've had no issue with the following combination: >>>>>>>> >>>>>>>> MesosDNS 0.4.0 >>>>>>>> Marathon 0.11.0 >>>>>>>> Mesos 0.24.1 >>>>>>>> >>>>>>>> I've been waiting to upgrade to Mesos 0.25.0 because of issues >>>>>>>> mentioned in the mesos mailing list regarding Marathon 0.11.x and Mesos >>>>>>>> 0.25.0 >>>>>>>> >>>>>>>> On Wed, Oct 28, 2015 at 10:38 AM, John Omernik <j...@omernik.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey all - >>>>>>>>> >>>>>>>>> I am cross posting this because it's a number of moving parts that >>>>>>>>> could be at issue here (Mesos, Mesos-dns, and/or Marathon). >>>>>>>>> >>>>>>>>> Basically: At the version combination in Subject, the IP that is >>>>>>>>> registered in mesos-dns for Docker containers running in Marathon is >>>>>>>>> the >>>>>>>>> internal (container) IP address of the docker (in bridged mode) not >>>>>>
Re: Marathon 0.11.1 - Mesos 0.25 - Mesos-DNS 0.4.0
What settings worked for you? We did aim for least surprise. Sounds like we missed a bit. We're happy to accept suggestions for improvement via gh issues filed against the mesos-dns repo. On Oct 29, 2015 7:39 AM, "John Omernik" <j...@omernik.com> wrote: > That is good to know, however, I would challenge the group on something > like this not being bug based on the documentation. When a change in > mesos-dns, and what fields it looks at is not affected by the mesos-dns > component, but instead other components in a way that could have serious > negative impacts on folks who are running this, there should be some > fanfare there about changes. Also, I would advocate that in mesos-dns the > default should have been the same as previous releases (which I would > assume was host ip) as default, then allow people who are aware of the > underpinnings to make the change. > > On Wed, Oct 28, 2015 at 3:02 PM, Grzegorz Graczyk <gregor...@gmail.com> > wrote: > >> It's not a bug, it's a feature - >> http://mesosphere.github.io/mesos-dns/docs/configuration-parameters.html look >> at IPSources config >> >> śr., 28.10.2015 o 15:59 użytkownik John Omernik <j...@omernik.com> >> napisał: >> >>> If I rolled back mesos-dns to v0.2.0 (on the releases page) then it >>> pulls the right IP address.. (Mesos-dns version is the easiest of the >>> three to change) >>> >>> John >>> >>> On Wed, Oct 28, 2015 at 9:52 AM, John Omernik <j...@omernik.com> wrote: >>> >>>> So, the issues that are listed appear to be resolved with marathon >>>> 0.11.1, and the mesos-dns issue is not listed at all. >>>> >>>> Note, I tried mesos-dns 0.3.0 and that has the same problem as 0.4.0. >>>> >>>> On Wed, Oct 28, 2015 at 9:46 AM, John Omernik <j...@omernik.com> wrote: >>>> >>>>> I will check out those issues and report back. >>>>> >>>>> On Wed, Oct 28, 2015 at 9:42 AM, craig w <codecr...@gmail.com> wrote: >>>>> >>>>>> I've had no issue with the following combination: >>>>>> >>>>>> MesosDNS 0.4.0 >>>>>> Marathon 0.11.0 >>>>>> Mesos 0.24.1 >>>>>> >>>>>> I've been waiting to upgrade to Mesos 0.25.0 because of issues >>>>>> mentioned in the mesos mailing list regarding Marathon 0.11.x and Mesos >>>>>> 0.25.0 >>>>>> >>>>>> On Wed, Oct 28, 2015 at 10:38 AM, John Omernik <j...@omernik.com> >>>>>> wrote: >>>>>> >>>>>>> Hey all - >>>>>>> >>>>>>> I am cross posting this because it's a number of moving parts that >>>>>>> could be at issue here (Mesos, Mesos-dns, and/or Marathon). >>>>>>> >>>>>>> Basically: At the version combination in Subject, the IP that is >>>>>>> registered in mesos-dns for Docker containers running in Marathon is the >>>>>>> internal (container) IP address of the docker (in bridged mode) not the >>>>>>> nodes. This obviously causes issues. Note this doesn't happen when the >>>>>>> Marathon application is non-Docker. >>>>>>> >>>>>>> I was running Mesos-dns 0.4.0 on a cluster running Mesos 0.24.0 and >>>>>>> Marathon 0.10.0 and I upgraded to Mesos 0.25.0 and Marathon 0.11.1 and >>>>>>> noticed this behavior happening. >>>>>>> >>>>>>> I thought that was odd because I have another cluster that was >>>>>>> running Mesos 0.25.0 and Marathon 0.11.1 and it wasn't happening, until >>>>>>> I >>>>>>> realized that I hadn't upgraded Mesos-dns lately, I upgraded to >>>>>>> Mesos-dns >>>>>>> 0.4.0 and the problem started occurring. >>>>>>> >>>>>>> Is there a setting that I need to use the external IP of the >>>>>>> container? Is this issue known? Is there a workaround? This is pretty >>>>>>> major >>>>>>> for Docker running on Marathon and using Mesos-dns for service >>>>>>> discovery. >>>>>>> >>>>>>> John Omernik >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> https://github.com/mindscratch >>>>>> https://www.google.com/+CraigWickesser >>>>>> https://twitter.com/mind_scratch >>>>>> https://twitter.com/craig_links >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "marathon-framework" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to marathon-framework+unsubscr...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "marathon-framework" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to marathon-framework+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > >
Re: Marathon 0.11.1 - Mesos 0.25 - Mesos-DNS 0.4.0
That is good to know, however, I would challenge the group on something like this not being bug based on the documentation. When a change in mesos-dns, and what fields it looks at is not affected by the mesos-dns component, but instead other components in a way that could have serious negative impacts on folks who are running this, there should be some fanfare there about changes. Also, I would advocate that in mesos-dns the default should have been the same as previous releases (which I would assume was host ip) as default, then allow people who are aware of the underpinnings to make the change. On Wed, Oct 28, 2015 at 3:02 PM, Grzegorz Graczyk <gregor...@gmail.com> wrote: > It's not a bug, it's a feature - > http://mesosphere.github.io/mesos-dns/docs/configuration-parameters.html look > at IPSources config > > śr., 28.10.2015 o 15:59 użytkownik John Omernik <j...@omernik.com> > napisał: > >> If I rolled back mesos-dns to v0.2.0 (on the releases page) then it pulls >> the right IP address.. (Mesos-dns version is the easiest of the three to >> change) >> >> John >> >> On Wed, Oct 28, 2015 at 9:52 AM, John Omernik <j...@omernik.com> wrote: >> >>> So, the issues that are listed appear to be resolved with marathon >>> 0.11.1, and the mesos-dns issue is not listed at all. >>> >>> Note, I tried mesos-dns 0.3.0 and that has the same problem as 0.4.0. >>> >>> On Wed, Oct 28, 2015 at 9:46 AM, John Omernik <j...@omernik.com> wrote: >>> >>>> I will check out those issues and report back. >>>> >>>> On Wed, Oct 28, 2015 at 9:42 AM, craig w <codecr...@gmail.com> wrote: >>>> >>>>> I've had no issue with the following combination: >>>>> >>>>> MesosDNS 0.4.0 >>>>> Marathon 0.11.0 >>>>> Mesos 0.24.1 >>>>> >>>>> I've been waiting to upgrade to Mesos 0.25.0 because of issues >>>>> mentioned in the mesos mailing list regarding Marathon 0.11.x and Mesos >>>>> 0.25.0 >>>>> >>>>> On Wed, Oct 28, 2015 at 10:38 AM, John Omernik <j...@omernik.com> >>>>> wrote: >>>>> >>>>>> Hey all - >>>>>> >>>>>> I am cross posting this because it's a number of moving parts that >>>>>> could be at issue here (Mesos, Mesos-dns, and/or Marathon). >>>>>> >>>>>> Basically: At the version combination in Subject, the IP that is >>>>>> registered in mesos-dns for Docker containers running in Marathon is the >>>>>> internal (container) IP address of the docker (in bridged mode) not the >>>>>> nodes. This obviously causes issues. Note this doesn't happen when the >>>>>> Marathon application is non-Docker. >>>>>> >>>>>> I was running Mesos-dns 0.4.0 on a cluster running Mesos 0.24.0 and >>>>>> Marathon 0.10.0 and I upgraded to Mesos 0.25.0 and Marathon 0.11.1 and >>>>>> noticed this behavior happening. >>>>>> >>>>>> I thought that was odd because I have another cluster that was >>>>>> running Mesos 0.25.0 and Marathon 0.11.1 and it wasn't happening, until I >>>>>> realized that I hadn't upgraded Mesos-dns lately, I upgraded to Mesos-dns >>>>>> 0.4.0 and the problem started occurring. >>>>>> >>>>>> Is there a setting that I need to use the external IP of the >>>>>> container? Is this issue known? Is there a workaround? This is pretty >>>>>> major >>>>>> for Docker running on Marathon and using Mesos-dns for service discovery. >>>>>> >>>>>> John Omernik >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> https://github.com/mindscratch >>>>> https://www.google.com/+CraigWickesser >>>>> https://twitter.com/mind_scratch >>>>> https://twitter.com/craig_links >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "marathon-framework" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to marathon-framework+unsubscr...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>> >> -- > You received this message because you are subscribed to the Google Groups > "marathon-framework" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to marathon-framework+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. >
Re: Marathon 0.11.1 - Mesos 0.25 - Mesos-DNS 0.4.0
I've had no issue with the following combination: MesosDNS 0.4.0 Marathon 0.11.0 Mesos 0.24.1 I've been waiting to upgrade to Mesos 0.25.0 because of issues mentioned in the mesos mailing list regarding Marathon 0.11.x and Mesos 0.25.0 On Wed, Oct 28, 2015 at 10:38 AM, John Omernik <j...@omernik.com> wrote: > Hey all - > > I am cross posting this because it's a number of moving parts that could > be at issue here (Mesos, Mesos-dns, and/or Marathon). > > Basically: At the version combination in Subject, the IP that is > registered in mesos-dns for Docker containers running in Marathon is the > internal (container) IP address of the docker (in bridged mode) not the > nodes. This obviously causes issues. Note this doesn't happen when the > Marathon application is non-Docker. > > I was running Mesos-dns 0.4.0 on a cluster running Mesos 0.24.0 and > Marathon 0.10.0 and I upgraded to Mesos 0.25.0 and Marathon 0.11.1 and > noticed this behavior happening. > > I thought that was odd because I have another cluster that was running > Mesos 0.25.0 and Marathon 0.11.1 and it wasn't happening, until I realized > that I hadn't upgraded Mesos-dns lately, I upgraded to Mesos-dns 0.4.0 and > the problem started occurring. > > Is there a setting that I need to use the external IP of the container? Is > this issue known? Is there a workaround? This is pretty major for Docker > running on Marathon and using Mesos-dns for service discovery. > > John Omernik > > > -- https://github.com/mindscratch https://www.google.com/+CraigWickesser https://twitter.com/mind_scratch https://twitter.com/craig_links
Marathon 0.11.1 - Mesos 0.25 - Mesos-DNS 0.4.0
Hey all - I am cross posting this because it's a number of moving parts that could be at issue here (Mesos, Mesos-dns, and/or Marathon). Basically: At the version combination in Subject, the IP that is registered in mesos-dns for Docker containers running in Marathon is the internal (container) IP address of the docker (in bridged mode) not the nodes. This obviously causes issues. Note this doesn't happen when the Marathon application is non-Docker. I was running Mesos-dns 0.4.0 on a cluster running Mesos 0.24.0 and Marathon 0.10.0 and I upgraded to Mesos 0.25.0 and Marathon 0.11.1 and noticed this behavior happening. I thought that was odd because I have another cluster that was running Mesos 0.25.0 and Marathon 0.11.1 and it wasn't happening, until I realized that I hadn't upgraded Mesos-dns lately, I upgraded to Mesos-dns 0.4.0 and the problem started occurring. Is there a setting that I need to use the external IP of the container? Is this issue known? Is there a workaround? This is pretty major for Docker running on Marathon and using Mesos-dns for service discovery. John Omernik
Re: Marathon 0.11.1 - Mesos 0.25 - Mesos-DNS 0.4.0
If I rolled back mesos-dns to v0.2.0 (on the releases page) then it pulls the right IP address.. (Mesos-dns version is the easiest of the three to change) John On Wed, Oct 28, 2015 at 9:52 AM, John Omernik <j...@omernik.com> wrote: > So, the issues that are listed appear to be resolved with marathon 0.11.1, > and the mesos-dns issue is not listed at all. > > Note, I tried mesos-dns 0.3.0 and that has the same problem as 0.4.0. > > On Wed, Oct 28, 2015 at 9:46 AM, John Omernik <j...@omernik.com> wrote: > >> I will check out those issues and report back. >> >> On Wed, Oct 28, 2015 at 9:42 AM, craig w <codecr...@gmail.com> wrote: >> >>> I've had no issue with the following combination: >>> >>> MesosDNS 0.4.0 >>> Marathon 0.11.0 >>> Mesos 0.24.1 >>> >>> I've been waiting to upgrade to Mesos 0.25.0 because of issues mentioned >>> in the mesos mailing list regarding Marathon 0.11.x and Mesos 0.25.0 >>> >>> On Wed, Oct 28, 2015 at 10:38 AM, John Omernik <j...@omernik.com> wrote: >>> >>>> Hey all - >>>> >>>> I am cross posting this because it's a number of moving parts that >>>> could be at issue here (Mesos, Mesos-dns, and/or Marathon). >>>> >>>> Basically: At the version combination in Subject, the IP that is >>>> registered in mesos-dns for Docker containers running in Marathon is the >>>> internal (container) IP address of the docker (in bridged mode) not the >>>> nodes. This obviously causes issues. Note this doesn't happen when the >>>> Marathon application is non-Docker. >>>> >>>> I was running Mesos-dns 0.4.0 on a cluster running Mesos 0.24.0 and >>>> Marathon 0.10.0 and I upgraded to Mesos 0.25.0 and Marathon 0.11.1 and >>>> noticed this behavior happening. >>>> >>>> I thought that was odd because I have another cluster that was running >>>> Mesos 0.25.0 and Marathon 0.11.1 and it wasn't happening, until I realized >>>> that I hadn't upgraded Mesos-dns lately, I upgraded to Mesos-dns 0.4.0 and >>>> the problem started occurring. >>>> >>>> Is there a setting that I need to use the external IP of the container? >>>> Is this issue known? Is there a workaround? This is pretty major for Docker >>>> running on Marathon and using Mesos-dns for service discovery. >>>> >>>> John Omernik >>>> >>>> >>>> >>> >>> >>> -- >>> >>> https://github.com/mindscratch >>> https://www.google.com/+CraigWickesser >>> https://twitter.com/mind_scratch >>> https://twitter.com/craig_links >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "marathon-framework" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to marathon-framework+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >
Re: Marathon 0.11.1 - Mesos 0.25 - Mesos-DNS 0.4.0
I will check out those issues and report back. On Wed, Oct 28, 2015 at 9:42 AM, craig w <codecr...@gmail.com> wrote: > I've had no issue with the following combination: > > MesosDNS 0.4.0 > Marathon 0.11.0 > Mesos 0.24.1 > > I've been waiting to upgrade to Mesos 0.25.0 because of issues mentioned > in the mesos mailing list regarding Marathon 0.11.x and Mesos 0.25.0 > > On Wed, Oct 28, 2015 at 10:38 AM, John Omernik <j...@omernik.com> wrote: > >> Hey all - >> >> I am cross posting this because it's a number of moving parts that could >> be at issue here (Mesos, Mesos-dns, and/or Marathon). >> >> Basically: At the version combination in Subject, the IP that is >> registered in mesos-dns for Docker containers running in Marathon is the >> internal (container) IP address of the docker (in bridged mode) not the >> nodes. This obviously causes issues. Note this doesn't happen when the >> Marathon application is non-Docker. >> >> I was running Mesos-dns 0.4.0 on a cluster running Mesos 0.24.0 and >> Marathon 0.10.0 and I upgraded to Mesos 0.25.0 and Marathon 0.11.1 and >> noticed this behavior happening. >> >> I thought that was odd because I have another cluster that was running >> Mesos 0.25.0 and Marathon 0.11.1 and it wasn't happening, until I realized >> that I hadn't upgraded Mesos-dns lately, I upgraded to Mesos-dns 0.4.0 and >> the problem started occurring. >> >> Is there a setting that I need to use the external IP of the container? >> Is this issue known? Is there a workaround? This is pretty major for Docker >> running on Marathon and using Mesos-dns for service discovery. >> >> John Omernik >> >> >> > > > -- > > https://github.com/mindscratch > https://www.google.com/+CraigWickesser > https://twitter.com/mind_scratch > https://twitter.com/craig_links > > -- > You received this message because you are subscribed to the Google Groups > "marathon-framework" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to marathon-framework+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. >
Re: Marathon 0.11.1 - Mesos 0.25 - Mesos-DNS 0.4.0
It's not a bug, it's a feature - http://mesosphere.github.io/mesos-dns/docs/configuration-parameters.html look at IPSources config śr., 28.10.2015 o 15:59 użytkownik John Omernik <j...@omernik.com> napisał: > If I rolled back mesos-dns to v0.2.0 (on the releases page) then it pulls > the right IP address.. (Mesos-dns version is the easiest of the three to > change) > > John > > On Wed, Oct 28, 2015 at 9:52 AM, John Omernik <j...@omernik.com> wrote: > >> So, the issues that are listed appear to be resolved with marathon >> 0.11.1, and the mesos-dns issue is not listed at all. >> >> Note, I tried mesos-dns 0.3.0 and that has the same problem as 0.4.0. >> >> On Wed, Oct 28, 2015 at 9:46 AM, John Omernik <j...@omernik.com> wrote: >> >>> I will check out those issues and report back. >>> >>> On Wed, Oct 28, 2015 at 9:42 AM, craig w <codecr...@gmail.com> wrote: >>> >>>> I've had no issue with the following combination: >>>> >>>> MesosDNS 0.4.0 >>>> Marathon 0.11.0 >>>> Mesos 0.24.1 >>>> >>>> I've been waiting to upgrade to Mesos 0.25.0 because of issues >>>> mentioned in the mesos mailing list regarding Marathon 0.11.x and Mesos >>>> 0.25.0 >>>> >>>> On Wed, Oct 28, 2015 at 10:38 AM, John Omernik <j...@omernik.com> >>>> wrote: >>>> >>>>> Hey all - >>>>> >>>>> I am cross posting this because it's a number of moving parts that >>>>> could be at issue here (Mesos, Mesos-dns, and/or Marathon). >>>>> >>>>> Basically: At the version combination in Subject, the IP that is >>>>> registered in mesos-dns for Docker containers running in Marathon is the >>>>> internal (container) IP address of the docker (in bridged mode) not the >>>>> nodes. This obviously causes issues. Note this doesn't happen when the >>>>> Marathon application is non-Docker. >>>>> >>>>> I was running Mesos-dns 0.4.0 on a cluster running Mesos 0.24.0 and >>>>> Marathon 0.10.0 and I upgraded to Mesos 0.25.0 and Marathon 0.11.1 and >>>>> noticed this behavior happening. >>>>> >>>>> I thought that was odd because I have another cluster that was running >>>>> Mesos 0.25.0 and Marathon 0.11.1 and it wasn't happening, until I realized >>>>> that I hadn't upgraded Mesos-dns lately, I upgraded to Mesos-dns 0.4.0 and >>>>> the problem started occurring. >>>>> >>>>> Is there a setting that I need to use the external IP of the >>>>> container? Is this issue known? Is there a workaround? This is pretty >>>>> major >>>>> for Docker running on Marathon and using Mesos-dns for service discovery. >>>>> >>>>> John Omernik >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> https://github.com/mindscratch >>>> https://www.google.com/+CraigWickesser >>>> https://twitter.com/mind_scratch >>>> https://twitter.com/craig_links >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "marathon-framework" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to marathon-framework+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> >
Re: Mesos-Dns Masters List
If you can, try mesos-dns 0.4.0, there were a handful of fixes and improvements that might help. 0.4.0 is working great for me. On Wed, Oct 14, 2015 at 9:10 AM, John Omernik <j...@omernik.com> wrote: > Hey all, > > I was using mesos-dns, and I filled in my zk field based on the HA mesos > cluster I have. Mesos dns is up, but in the stderr, I keep seeing > "generator.go:342 warning: leader "master@10.0.0.1:5050" is not in master > list. > > I don't have a master list in my config.json, instead I am using the zk > list. but the 10.0.0.1 is a valid master which is running properly. I am > running Mesos 0.24 and mesos-dns 0.3.0. Any thoughts on this? > > John > -- https://github.com/mindscratch https://www.google.com/+CraigWickesser https://twitter.com/mind_scratch https://twitter.com/craig_links
Mesos-Dns Masters List
Hey all, I was using mesos-dns, and I filled in my zk field based on the HA mesos cluster I have. Mesos dns is up, but in the stderr, I keep seeing "generator.go:342 warning: leader "master@10.0.0.1:5050" is not in master list. I don't have a master list in my config.json, instead I am using the zk list. but the 10.0.0.1 is a valid master which is running properly. I am running Mesos 0.24 and mesos-dns 0.3.0. Any thoughts on this? John
Re: Mesos-DNS host based HTTP-redirection from slave to container
But this nginx reverse proxy for docker only scales to one host. Can someone confirm if it has worked for multiple slaves? What is the most common engine everyone uses for load balancing an app with multiple tasks/docker containers? Shafay Latif On Aug 3, 2015, at 9:44 AM, Itamar Ostricher ita...@yowza3d.com wrote: Thanks! I also found this automated nginx reverse proxy for docker - http://jasonwilder.com/blog/2014/03/25/automated-nginx-reverse-proxy-for-docker/ Looks like a very similar process, that takes advantage of the docker events API. I think I was able to get it working. Ryan, how does this approach compares to bamboo? Thanks a lot! On Sun, Aug 2, 2015 at 1:21 PM Ryan Thomas r.n.tho...@gmail.com wrote: If you are going to be pulling data down yourself it would be better to do it from marathon, than mesos-dns as you will have additional data about the tasks available. On 2 August 2015 at 11:12, tommy xiao xia...@gmail.com wrote: mesos-dns store the app's IP and ports. so you can query the mesos-dns to setup a route rule to define the url. 2015-08-02 17:51 GMT+08:00 Ryan Thomas r.n.tho...@gmail.com: Yes it appears that mesos-dns does use SRV records - I should really check it out :) On 2 August 2015 at 10:50, Ryan Thomas r.n.tho...@gmail.com wrote: Hey Itamar, Using DNS to redirect to a port will only be possible if you're using SRV records (I'm not sure what mesos-dns uses) but this doesn't really matter as it won't be looked up by the browser. For this solution I have a small daemon written in go running on a number of hosts (that aren't slaves), this locates the marathon master, and pulls down my apps - I tag apps with a Host label (something like foo.example.com) and then I create a haproxy config file with backends directed by the host header. There's a few more smarts in it around only pulling apps with a green healthcheck etc. This daemon manages the lifecycle of haproxy on the node - it uses a polling model, not an event driven one from the marathon event stream. Another solution that uses the event-stream is this one https://github.com/QubitProducts/bamboo - it's been a while since I checked it out, but was functional back then. Hope that helps. ryan On 2 August 2015 at 07:10, Itamar Ostricher ita...@yowza3d.com wrote: I use marathon to launch a nginx-docker-container named my-app, and set up Mesos-DNS, such that my-app.marathon.mesos returns the IP of the slave running the container (e.g. 10.20.30.40). Now, my-app is running on some dynamically-allocated port (e.g. 31001), but I would like http://my-app.marathon.mesos/foo to hit my app at http://10.20.30.40:31001/foo Is there a best practice way to achieve this behavior? I was thinking about a proxy running on each slave, listening on port 80, redirecting incoming HTTP requests based on the request host to the correct port on localhost. The correct port can be determined by querying mesos-dns itself. This sounds like a pretty common use-case, so I wondered if anyone can point me at an existing solution for this. Thanks! - Itamar. -- Deshi Xiao Twitter: xds2000 E-mail: xiaods(AT)gmail.com
Re: Mesos-DNS host based HTTP-redirection from slave to container
what do you mean only scales to one host? I have multiple slaves, and I plan to run it on every slave as a service (just like the mesos slave service itself), probably outside of marathon. On Wed, Aug 5, 2015 at 7:26 PM Shafay Latif sla...@apple.com wrote: But this nginx reverse proxy for docker only scales to one host. Can someone confirm if it has worked for multiple slaves? What is the most common engine everyone uses for load balancing an app with multiple tasks/docker containers? Shafay Latif On Aug 3, 2015, at 9:44 AM, Itamar Ostricher ita...@yowza3d.com wrote: Thanks! I also found this automated nginx reverse proxy for docker - http://jasonwilder.com/blog/2014/03/25/automated-nginx-reverse-proxy-for-docker/ Looks like a very similar process, that takes advantage of the docker events API. I think I was able to get it working. Ryan, how does this approach compares to bamboo? Thanks a lot! On Sun, Aug 2, 2015 at 1:21 PM Ryan Thomas r.n.tho...@gmail.com wrote: If you are going to be pulling data down yourself it would be better to do it from marathon, than mesos-dns as you will have additional data about the tasks available. On 2 August 2015 at 11:12, tommy xiao xia...@gmail.com wrote: mesos-dns store the app's IP and ports. so you can query the mesos-dns to setup a route rule to define the url. 2015-08-02 17:51 GMT+08:00 Ryan Thomas r.n.tho...@gmail.com: Yes it appears that mesos-dns does use SRV records - I should really check it out :) On 2 August 2015 at 10:50, Ryan Thomas r.n.tho...@gmail.com wrote: Hey Itamar, Using DNS to redirect to a port will only be possible if you're using SRV records (I'm not sure what mesos-dns uses) but this doesn't really matter as it won't be looked up by the browser. For this solution I have a small daemon written in go running on a number of hosts (that aren't slaves), this locates the marathon master, and pulls down my apps - I tag apps with a Host label (something like foo.example.com) and then I create a haproxy config file with backends directed by the host header. There's a few more smarts in it around only pulling apps with a green healthcheck etc. This daemon manages the lifecycle of haproxy on the node - it uses a polling model, not an event driven one from the marathon event stream. Another solution that uses the event-stream is this one https://github.com/QubitProducts/bamboo - it's been a while since I checked it out, but was functional back then. Hope that helps. ryan On 2 August 2015 at 07:10, Itamar Ostricher ita...@yowza3d.com wrote: I use marathon to launch a nginx-docker-container named my-app, and set up Mesos-DNS, such that my-app.marathon.mesos returns the IP of the slave running the container (e.g. 10.20.30.40). Now, my-app is running on some dynamically-allocated port (e.g. 31001), but I would like http://my-app.marathon.mesos/foo to hit my app at http://10.20.30.40:31001/foo Is there a best practice way to achieve this behavior? I was thinking about a proxy running on each slave, listening on port 80, redirecting incoming HTTP requests based on the request host to the correct port on localhost. The correct port can be determined by querying mesos-dns itself. This sounds like a pretty common use-case, so I wondered if anyone can point me at an existing solution for this. Thanks! - Itamar. -- Deshi Xiao Twitter: xds2000 E-mail: xiaods(AT)gmail.com
Mesos-DNS host based HTTP-redirection from slave to container
I use marathon to launch a nginx-docker-container named my-app, and set up Mesos-DNS, such that my-app.marathon.mesos returns the IP of the slave running the container (e.g. 10.20.30.40). Now, my-app is running on some dynamically-allocated port (e.g. 31001), but I would like http://my-app.marathon.mesos/foo to hit my app at http://10.20.30.40:31001/foo Is there a best practice way to achieve this behavior? I was thinking about a proxy running on each slave, listening on port 80, redirecting incoming HTTP requests based on the request host to the correct port on localhost. The correct port can be determined by querying mesos-dns itself. This sounds like a pretty common use-case, so I wondered if anyone can point me at an existing solution for this. Thanks! - Itamar.
Re: Mesos-DNS host based HTTP-redirection from slave to container
mesos-dns store the app's IP and ports. so you can query the mesos-dns to setup a route rule to define the url. 2015-08-02 17:51 GMT+08:00 Ryan Thomas r.n.tho...@gmail.com: Yes it appears that mesos-dns does use SRV records - I should really check it out :) On 2 August 2015 at 10:50, Ryan Thomas r.n.tho...@gmail.com wrote: Hey Itamar, Using DNS to redirect to a port will only be possible if you're using SRV records (I'm not sure what mesos-dns uses) but this doesn't really matter as it won't be looked up by the browser. For this solution I have a small daemon written in go running on a number of hosts (that aren't slaves), this locates the marathon master, and pulls down my apps - I tag apps with a Host label (something like foo.example.com) and then I create a haproxy config file with backends directed by the host header. There's a few more smarts in it around only pulling apps with a green healthcheck etc. This daemon manages the lifecycle of haproxy on the node - it uses a polling model, not an event driven one from the marathon event stream. Another solution that uses the event-stream is this one https://github.com/QubitProducts/bamboo - it's been a while since I checked it out, but was functional back then. Hope that helps. ryan On 2 August 2015 at 07:10, Itamar Ostricher ita...@yowza3d.com wrote: I use marathon to launch a nginx-docker-container named my-app, and set up Mesos-DNS, such that my-app.marathon.mesos returns the IP of the slave running the container (e.g. 10.20.30.40). Now, my-app is running on some dynamically-allocated port (e.g. 31001), but I would like http://my-app.marathon.mesos/foo to hit my app at http://10.20.30.40:31001/foo Is there a best practice way to achieve this behavior? I was thinking about a proxy running on each slave, listening on port 80, redirecting incoming HTTP requests based on the request host to the correct port on localhost. The correct port can be determined by querying mesos-dns itself. This sounds like a pretty common use-case, so I wondered if anyone can point me at an existing solution for this. Thanks! - Itamar. -- Deshi Xiao Twitter: xds2000 E-mail: xiaods(AT)gmail.com
Re: Mesos-DNS host based HTTP-redirection from slave to container
Hey Itamar, Using DNS to redirect to a port will only be possible if you're using SRV records (I'm not sure what mesos-dns uses) but this doesn't really matter as it won't be looked up by the browser. For this solution I have a small daemon written in go running on a number of hosts (that aren't slaves), this locates the marathon master, and pulls down my apps - I tag apps with a Host label (something like foo.example.com) and then I create a haproxy config file with backends directed by the host header. There's a few more smarts in it around only pulling apps with a green healthcheck etc. This daemon manages the lifecycle of haproxy on the node - it uses a polling model, not an event driven one from the marathon event stream. Another solution that uses the event-stream is this one https://github.com/QubitProducts/bamboo - it's been a while since I checked it out, but was functional back then. Hope that helps. ryan On 2 August 2015 at 07:10, Itamar Ostricher ita...@yowza3d.com wrote: I use marathon to launch a nginx-docker-container named my-app, and set up Mesos-DNS, such that my-app.marathon.mesos returns the IP of the slave running the container (e.g. 10.20.30.40). Now, my-app is running on some dynamically-allocated port (e.g. 31001), but I would like http://my-app.marathon.mesos/foo to hit my app at http://10.20.30.40:31001/foo Is there a best practice way to achieve this behavior? I was thinking about a proxy running on each slave, listening on port 80, redirecting incoming HTTP requests based on the request host to the correct port on localhost. The correct port can be determined by querying mesos-dns itself. This sounds like a pretty common use-case, so I wondered if anyone can point me at an existing solution for this. Thanks! - Itamar.
Re: Mesos-DNS host based HTTP-redirection from slave to container
Yes it appears that mesos-dns does use SRV records - I should really check it out :) On 2 August 2015 at 10:50, Ryan Thomas r.n.tho...@gmail.com wrote: Hey Itamar, Using DNS to redirect to a port will only be possible if you're using SRV records (I'm not sure what mesos-dns uses) but this doesn't really matter as it won't be looked up by the browser. For this solution I have a small daemon written in go running on a number of hosts (that aren't slaves), this locates the marathon master, and pulls down my apps - I tag apps with a Host label (something like foo.example.com) and then I create a haproxy config file with backends directed by the host header. There's a few more smarts in it around only pulling apps with a green healthcheck etc. This daemon manages the lifecycle of haproxy on the node - it uses a polling model, not an event driven one from the marathon event stream. Another solution that uses the event-stream is this one https://github.com/QubitProducts/bamboo - it's been a while since I checked it out, but was functional back then. Hope that helps. ryan On 2 August 2015 at 07:10, Itamar Ostricher ita...@yowza3d.com wrote: I use marathon to launch a nginx-docker-container named my-app, and set up Mesos-DNS, such that my-app.marathon.mesos returns the IP of the slave running the container (e.g. 10.20.30.40). Now, my-app is running on some dynamically-allocated port (e.g. 31001), but I would like http://my-app.marathon.mesos/foo to hit my app at http://10.20.30.40:31001/foo Is there a best practice way to achieve this behavior? I was thinking about a proxy running on each slave, listening on port 80, redirecting incoming HTTP requests based on the request host to the correct port on localhost. The correct port can be determined by querying mesos-dns itself. This sounds like a pretty common use-case, so I wondered if anyone can point me at an existing solution for this. Thanks! - Itamar.
Re: Mesos-DNS host based HTTP-redirection from slave to container
If you are going to be pulling data down yourself it would be better to do it from marathon, than mesos-dns as you will have additional data about the tasks available. On 2 August 2015 at 11:12, tommy xiao xia...@gmail.com wrote: mesos-dns store the app's IP and ports. so you can query the mesos-dns to setup a route rule to define the url. 2015-08-02 17:51 GMT+08:00 Ryan Thomas r.n.tho...@gmail.com: Yes it appears that mesos-dns does use SRV records - I should really check it out :) On 2 August 2015 at 10:50, Ryan Thomas r.n.tho...@gmail.com wrote: Hey Itamar, Using DNS to redirect to a port will only be possible if you're using SRV records (I'm not sure what mesos-dns uses) but this doesn't really matter as it won't be looked up by the browser. For this solution I have a small daemon written in go running on a number of hosts (that aren't slaves), this locates the marathon master, and pulls down my apps - I tag apps with a Host label (something like foo.example.com) and then I create a haproxy config file with backends directed by the host header. There's a few more smarts in it around only pulling apps with a green healthcheck etc. This daemon manages the lifecycle of haproxy on the node - it uses a polling model, not an event driven one from the marathon event stream. Another solution that uses the event-stream is this one https://github.com/QubitProducts/bamboo - it's been a while since I checked it out, but was functional back then. Hope that helps. ryan On 2 August 2015 at 07:10, Itamar Ostricher ita...@yowza3d.com wrote: I use marathon to launch a nginx-docker-container named my-app, and set up Mesos-DNS, such that my-app.marathon.mesos returns the IP of the slave running the container (e.g. 10.20.30.40). Now, my-app is running on some dynamically-allocated port (e.g. 31001), but I would like http://my-app.marathon.mesos/foo to hit my app at http://10.20.30.40:31001/foo Is there a best practice way to achieve this behavior? I was thinking about a proxy running on each slave, listening on port 80, redirecting incoming HTTP requests based on the request host to the correct port on localhost. The correct port can be determined by querying mesos-dns itself. This sounds like a pretty common use-case, so I wondered if anyone can point me at an existing solution for this. Thanks! - Itamar. -- Deshi Xiao Twitter: xds2000 E-mail: xiaods(AT)gmail.com
Can't get SRV records from Mesos-DNS
Hi,
I just set up mesos-dns with my mesos+marathon cluster, and it appears to
be working fine, but I can't get SRV records.
mesos-dns executed by running: $ sudo /usr/local/mesos-dns/mesos-dns
-config /usr/local/mesos-dns/config.json
verified to be working by running dig from another machine after updating
its /etc/resolv.conf:
$ dig +short search3d.marathon.mesos
10.240.76.32
10.240.175.55
not sure though how to get SRV records for the service port numbers...
$ nslookup -type=SRV search3d.marathon.mesos
Server: 10.240.28.7
Address: 10.240.28.7#53
*** Can't find search3d.marathon.mesos: No answer
Here's the config file:
$ cat /usr/local/mesos-dns/config.json
{
zk: zk://10.240.28.7:2181,10.240.168.92:2181,10.240.251.236:2181/mesos
,
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 53,
resolvers: [169.254.169.254, 10.240.0.1],
timeout: 5,
email: root.mesos-dns.mesos
}
running latest version AFAIK:
$ /usr/local/mesos-dns/mesos-dns -version
0.1.2
Am I doing something wrong?
Thanks!
- Itamar.
Re: Can't get SRV records from Mesos-DNS
What does
dig _search3d._tcp.marathon.mesos SRV
give you?
See also http://mesosphere.github.io/mesos-dns/docs/naming.html
Cheers,
Michael
--
Michael Hausenblas
Ireland, Europe
http://mhausenblas.info/
On 28 Jul 2015, at 17:14, Itamar Ostricher ita...@yowza3d.com wrote:
Hi,
I just set up mesos-dns with my mesos+marathon cluster, and it appears to be
working fine, but I can't get SRV records.
mesos-dns executed by running: $ sudo /usr/local/mesos-dns/mesos-dns -config
/usr/local/mesos-dns/config.json
verified to be working by running dig from another machine after updating
its /etc/resolv.conf:
$ dig +short search3d.marathon.mesos
10.240.76.32
10.240.175.55
not sure though how to get SRV records for the service port numbers...
$ nslookup -type=SRV search3d.marathon.mesos
Server: 10.240.28.7
Address: 10.240.28.7#53
*** Can't find search3d.marathon.mesos: No answer
Here's the config file:
$ cat /usr/local/mesos-dns/config.json
{
zk: zk://10.240.28.7:2181,10.240.168.92:2181,10.240.251.236:2181/mesos,
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 53,
resolvers: [169.254.169.254, 10.240.0.1],
timeout: 5,
email: root.mesos-dns.mesos
}
running latest version AFAIK:
$ /usr/local/mesos-dns/mesos-dns -version
0.1.2
Am I doing something wrong?
Thanks!
- Itamar.
RE: Can't get SRV records from Mesos-DNS
Hi Itamar,
You need to change the dns name you’re querying for a bit:
Use dig _search3d._tcp.marathon.mesos
See: https://mesosphere.github.io/mesos-dns/docs/naming.html#srv-records
Andras
From: Itamar Ostricher [mailto:ita...@yowza3d.com]
Sent: Tuesday, July 28, 2015 12:15 PM
To: user@mesos.apache.org
Subject: Can't get SRV records from Mesos-DNS
Hi,
I just set up mesos-dns with my mesos+marathon cluster, and it appears to be
working fine, but I can't get SRV records.
mesos-dns executed by running: $ sudo /usr/local/mesos-dns/mesos-dns -config
/usr/local/mesos-dns/config.json
verified to be working by running dig from another machine after updating its
/etc/resolv.conf:
$ dig +short search3d.marathon.mesos
10.240.76.32
10.240.175.55
not sure though how to get SRV records for the service port numbers...
$ nslookup -type=SRV search3d.marathon.mesos
Server: 10.240.28.7
Address: 10.240.28.7#53
*** Can't find search3d.marathon.mesos: No answer
Here's the config file:
$ cat /usr/local/mesos-dns/config.json
{
zk: zk://10.240.28.7:2181,10.240.168.92:2181,10.240.251.236:2181/mesos,
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 53,
resolvers: [169.254.169.254, 10.240.0.1],
timeout: 5,
email: root.mesos-dns.mesos
}
running latest version AFAIK:
$ /usr/local/mesos-dns/mesos-dns -version
0.1.2
Am I doing something wrong?
Thanks!
- Itamar.
smime.p7s
Description: S/MIME cryptographic signature
Re: Can't get SRV records from Mesos-DNS
ah, thanks! missed that part... it did the trick :-)
On Tue, Jul 28, 2015 at 7:25 PM Andras Kerekes
andras.kere...@ishisystems.com wrote:
Hi Itamar,
You need to change the dns name you’re querying for a bit:
Use *dig _search3d._tcp.marathon.mesos*
See: https://mesosphere.github.io/mesos-dns/docs/naming.html#srv-records
Andras
*From:* Itamar Ostricher [mailto:ita...@yowza3d.com]
*Sent:* Tuesday, July 28, 2015 12:15 PM
*To:* user@mesos.apache.org
*Subject:* Can't get SRV records from Mesos-DNS
Hi,
I just set up mesos-dns with my mesos+marathon cluster, and it appears to
be working fine, but I can't get SRV records.
mesos-dns executed by running: $ sudo /usr/local/mesos-dns/mesos-dns
-config /usr/local/mesos-dns/config.json
verified to be working by running dig from another machine after
updating its /etc/resolv.conf:
$ dig +short search3d.marathon.mesos
10.240.76.32
10.240.175.55
not sure though how to get SRV records for the service port numbers...
$ nslookup -type=SRV search3d.marathon.mesos
Server: 10.240.28.7
Address: 10.240.28.7#53
*** Can't find search3d.marathon.mesos: No answer
Here's the config file:
$ cat /usr/local/mesos-dns/config.json
{
zk: zk://10.240.28.7:2181,10.240.168.92:2181,
10.240.251.236:2181/mesos,
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 53,
resolvers: [169.254.169.254, 10.240.0.1],
timeout: 5,
email: root.mesos-dns.mesos
}
running latest version AFAIK:
$ /usr/local/mesos-dns/mesos-dns -version
0.1.2
Am I doing something wrong?
Thanks!
- Itamar.
Re: Mesos-DNS configuration problem with dockerized web application
It’s not possible now, but hopefully it will be in the future. Related mesos
issue: https://issues.apache.org/jira/browse/MESOS-2044
https://issues.apache.org/jira/browse/MESOS-2044
On 16 Jul 2015, at 22:57, Ondrej Smola ondrej.sm...@gmail.com wrote:
I dont think there is way how can MesosDNS help you in this case ... when you
rely on classic DNS lookups - they are based on looking up DNS - IP (a,
records) - there is no port lookup (they use port you provide).
https://mesosphere.github.io/marathon/docs/service-discovery-load-balancing.html
https://mesosphere.github.io/marathon/docs/service-discovery-load-balancing.html
is a good starting point.
2015-07-16 22:24 GMT+02:00 Dvorkin-Contractor, Eugene (CORP)
eugene.dvorkin-contrac...@adp.com
mailto:eugene.dvorkin-contrac...@adp.com:
Thanks. I was hoping that mesos-dns will do it for me and I can run services
on different ports even on the same node. I was hesitant to use HAProxy.
I think I have to use HAProxy/Bamboo to achieve this functionality.
From: Ondrej Smola ondrej.sm...@gmail.com mailto:ondrej.sm...@gmail.com
Reply-To: user@mesos.apache.org mailto:user@mesos.apache.org
user@mesos.apache.org mailto:user@mesos.apache.org
Date: Thursday, July 16, 2015 at 2:55 PM
To: user@mesos.apache.org mailto:user@mesos.apache.org
user@mesos.apache.org mailto:user@mesos.apache.org
Subject: Re: Mesos-DNS configuration problem with dockerized web application
Hi,
portMappings: [
{ containerPort: 8080, hostPort: 80, servicePort: 9000,
protocol: tcp }
]
will work - you need to specify required port as hostPort
only limitation of this setup is that you wont be able to run multiple
services on single host with same hostPort (port collision)
but for most setups you should be ok with just choosing random/different
ports for different services or ensuring there are more nodes than requested
instances with same port
if you want to use random port - you will need some have logic to query DNS
and parse SRV records and for example setup HA proxy with correctly assigned
ports
this problem can also be solved using SDN (for example flannel/weave -)
assigning each service unique IP address and dont care about port collisions
- but this is not related to MesosDNS - just info :)
2015-07-16 17:58 GMT+02:00 Dvorkin-Contractor, Eugene (CORP)
eugene.dvorkin-contrac...@adp.com
mailto:eugene.dvorkin-contrac...@adp.com:
Hi,
I can’t access my application using mesos-dns. Neither port 8123 nor 8080
responding. I think I miss something in configuration but can’t find problem
myself.
I have a very basic java application that listen on port 8080. I have created
docker image and deployed this application to marathon.
My deployment configuration is following:
$ cat app-slick.json
{
container: {
type: DOCKER,
docker: {
image: edvorkin/slick-swagger:1,
network: BRIDGE,
portMappings: [
{ containerPort: 8080, hostPort: 0, servicePort: 9000,
protocol: tcp }
]
}
},
cmd: java -jar /tmp/spray-slick-swagger-assembly-0.0.2.jar Boot,
id: slick-swagger-demo,
instances: 1,
cpus: 0.1,
mem: 256,
constraints: [
[hostname, UNIQUE]
]
}
Application successfully deployed to 2 nodes and assigned random port of
31990 and 31000 on each node.
Now I installed and configured Mesos-DNS with config.json
{
zk: zk://172.31.50.58:2181 http://172.31.50.58:2181/,172.31.50.59:2181
http://172.31.50.59:2181/,172.31.50.60:2181/mesos
http://172.31.50.60:2181/mesos,
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 53,
resolvers: [172.31.0.2],
timeout: 5,
email: root.mesos-dns.mesos
}
and I got following:
$ dig slick-swagger-demo.marathon.mesos
; DiG 9.9.4-RedHat-9.9.4-18.el7_1.1
slick-swagger-demo.marathon.mesos
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 20376
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;slick-swagger-demo.marathon.mesos. IN A
;; ANSWER SECTION:
slick-swagger-demo.marathon.mesos. 60 IN A 172.31.11.202
slick-swagger-demo.marathon.mesos. 60 IN A 172.31.11.203
;; Query time: 1 msec
;; SERVER: 54.86.164.193#53(54.86.164.193)
;; WHEN: Thu Jul 16 15:23:04 UTC 2015
;; MSG SIZE rcvd: 83
curl
http://localhost:8123/v1/services/_slick-swagger-demo._tcp.marathon.mesos
http://localhost:8123/v1/services/_slick-swagger-demo._tcp.marathon.mesos
|python -m json.tool
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft Speed
100 289 100 2890 0 1916 0 --:--:-- --:--:-- --:--:-- 1926
[
{
host: slick-swagger-demo-15491-s42.marathon.mesos.,
ip: 172.31.11.203,
port: 31990,
service
Mesos-DNS configuration problem with dockerized web application
Hi,
I can’t access my application using mesos-dns. Neither port 8123 nor 8080
responding. I think I miss something in configuration but can’t find problem
myself.
I have a very basic java application that listen on port 8080. I have created
docker image and deployed this application to marathon.
My deployment configuration is following:
$ cat app-slick.json
{
container: {
type: DOCKER,
docker: {
image: edvorkin/slick-swagger:1,
network: BRIDGE,
portMappings: [
{ containerPort: 8080, hostPort: 0, servicePort: 9000,
protocol: tcp }
]
}
},
cmd: java -jar /tmp/spray-slick-swagger-assembly-0.0.2.jar Boot,
id: slick-swagger-demo,
instances: 1,
cpus: 0.1,
mem: 256,
constraints: [
[hostname, UNIQUE]
]
}
Application successfully deployed to 2 nodes and assigned random port of 31990
and 31000 on each node.
Now I installed and configured Mesos-DNS with config.json
{
zk: zk://172.31.50.58:2181,172.31.50.59:2181,172.31.50.60:2181/mesos,
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 53,
resolvers: [172.31.0.2],
timeout: 5,
email: root.mesos-dns.mesos
}
and I got following:
$ dig slick-swagger-demo.marathon.mesos
; DiG 9.9.4-RedHat-9.9.4-18.el7_1.1 slick-swagger-demo.marathon.mesos
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 20376
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;slick-swagger-demo.marathon.mesos. IN A
;; ANSWER SECTION:
slick-swagger-demo.marathon.mesos. 60 IN A 172.31.11.202
slick-swagger-demo.marathon.mesos. 60 IN A 172.31.11.203
;; Query time: 1 msec
;; SERVER: 54.86.164.193#53(54.86.164.193)
;; WHEN: Thu Jul 16 15:23:04 UTC 2015
;; MSG SIZE rcvd: 83
curl http://localhost:8123/v1/services/_slick-swagger-demo._tcp.marathon.mesos
|python -m json.tool
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 289 100 2890 0 1916 0 --:--:-- --:--:-- --:--:-- 1926
[
{
host: slick-swagger-demo-15491-s42.marathon.mesos.,
ip: 172.31.11.203,
port: 31990,
service: _slick-swagger-demo._tcp.marathon.mesos
},
{
host: slick-swagger-demo-20495-s43.marathon.mesos.,
ip: 172.31.11.202,
port: 31000,
service: _slick-swagger-demo._tcp.marathon.mesos
}
]
But when I try to access my application using dns name, I can’t get get
response.
curl http://slick-swagger-demo.marathon.mesos:8080
curl: (7) Failed connect to slick-swagger-demo.marathon.mesos:8080; Connection
refused
curl slick-swagger-demo.marathon.mesos:8123
404: Page Not Found
curl slick-swagger-demo.marathon.mesos:31990 – produce desired results, but
that binded to a random port.
How do I configure mapping between random ports and my service?
I would like to be able to access my server on port 80 for example
Curl http://slick-swagger-demo.marathon.mesos
Thanks
Eugene
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, notify the sender immediately by return email and delete the message
and any attachments from your system.
Re: Mesos-DNS configuration problem with dockerized web application
Thanks. I was hoping that mesos-dns will do it for me and I can run services
on different ports even on the same node. I was hesitant to use HAProxy.
I think I have to use HAProxy/Bamboo to achieve this functionality.
From: Ondrej Smola ondrej.sm...@gmail.commailto:ondrej.sm...@gmail.com
Reply-To: user@mesos.apache.orgmailto:user@mesos.apache.org
user@mesos.apache.orgmailto:user@mesos.apache.org
Date: Thursday, July 16, 2015 at 2:55 PM
To: user@mesos.apache.orgmailto:user@mesos.apache.org
user@mesos.apache.orgmailto:user@mesos.apache.org
Subject: Re: Mesos-DNS configuration problem with dockerized web application
Hi,
portMappings: [
{ containerPort: 8080, hostPort: 80, servicePort: 9000,
protocol: tcp }
]
will work - you need to specify required port as hostPort
only limitation of this setup is that you wont be able to run multiple
services on single host with same hostPort (port collision)
but for most setups you should be ok with just choosing random/different ports
for different services or ensuring there are more nodes than requested
instances with same port
if you want to use random port - you will need some have logic to query DNS and
parse SRV records and for example setup HA proxy with correctly assigned ports
this problem can also be solved using SDN (for example flannel/weave -)
assigning each service unique IP address and dont care about port collisions -
but this is not related to MesosDNS - just info :)
2015-07-16 17:58 GMT+02:00 Dvorkin-Contractor, Eugene (CORP)
eugene.dvorkin-contrac...@adp.commailto:eugene.dvorkin-contrac...@adp.com:
Hi,
I can’t access my application using mesos-dns. Neither port 8123 nor 8080
responding. I think I miss something in configuration but can’t find problem
myself.
I have a very basic java application that listen on port 8080. I have created
docker image and deployed this application to marathon.
My deployment configuration is following:
$ cat app-slick.json
{
container: {
type: DOCKER,
docker: {
image: edvorkin/slick-swagger:1,
network: BRIDGE,
portMappings: [
{ containerPort: 8080, hostPort: 0, servicePort: 9000,
protocol: tcp }
]
}
},
cmd: java -jar /tmp/spray-slick-swagger-assembly-0.0.2.jar Boot,
id: slick-swagger-demo,
instances: 1,
cpus: 0.1,
mem: 256,
constraints: [
[hostname, UNIQUE]
]
}
Application successfully deployed to 2 nodes and assigned random port of 31990
and 31000 on each node.
Now I installed and configured Mesos-DNS with config.json
{
zk:
zk://172.31.50.58:2181http://172.31.50.58:2181,172.31.50.59:2181http://172.31.50.59:2181,172.31.50.60:2181/mesoshttp://172.31.50.60:2181/mesos,
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 53,
resolvers: [172.31.0.2],
timeout: 5,
email: root.mesos-dns.mesos
}
and I got following:
$ dig slick-swagger-demo.marathon.mesos
; DiG 9.9.4-RedHat-9.9.4-18.el7_1.1 slick-swagger-demo.marathon.mesos
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 20376
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;slick-swagger-demo.marathon.mesos. IN A
;; ANSWER SECTION:
slick-swagger-demo.marathon.mesos. 60 IN A 172.31.11.202
slick-swagger-demo.marathon.mesos. 60 IN A 172.31.11.203
;; Query time: 1 msec
;; SERVER: 54.86.164.193#53(54.86.164.193)
;; WHEN: Thu Jul 16 15:23:04 UTC 2015
;; MSG SIZE rcvd: 83
curl http://localhost:8123/v1/services/_slick-swagger-demo._tcp.marathon.mesos
|python -m json.tool
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
100 289 100 2890 0 1916 0 --:--:-- --:--:-- --:--:-- 1926
[
{
host: slick-swagger-demo-15491-s42.marathon.mesos.,
ip: 172.31.11.203,
port: 31990,
service: _slick-swagger-demo._tcp.marathon.mesos
},
{
host: slick-swagger-demo-20495-s43.marathon.mesos.,
ip: 172.31.11.202,
port: 31000,
service: _slick-swagger-demo._tcp.marathon.mesos
}
]
But when I try to access my application using dns name, I can’t get get
response.
curl http://slick-swagger-demo.marathon.mesos:8080
curl: (7) Failed connect to slick-swagger-demo.marathon.mesos:8080; Connection
refused
curl slick-swagger-demo.marathon.mesos:8123
404: Page Not Found
curl slick-swagger-demo.marathon.mesos:31990 – produce desired results, but
that binded to a random port.
How do I configure mapping between random ports and my service?
I would like to be able to access my server on port 80 for example
Curl http://slick-swagger-demo.marathon.mesos
Thanks
Eugene
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended
Re: Mesos-DNS configuration problem with dockerized web application
I dont think there is way how can MesosDNS help you in this case ... when
you rely on classic DNS lookups - they are based on looking up DNS - IP
(a, records) - there is no port lookup (they use port you provide).
https://mesosphere.github.io/marathon/docs/service-discovery-load-balancing.html
is a good starting point.
2015-07-16 22:24 GMT+02:00 Dvorkin-Contractor, Eugene (CORP)
eugene.dvorkin-contrac...@adp.com:
Thanks. I was hoping that mesos-dns will do it for me and I can run
services on different ports even on the same node. I was hesitant to use
HAProxy.
I think I have to use HAProxy/Bamboo to achieve this functionality.
From: Ondrej Smola ondrej.sm...@gmail.com
Reply-To: user@mesos.apache.org user@mesos.apache.org
Date: Thursday, July 16, 2015 at 2:55 PM
To: user@mesos.apache.org user@mesos.apache.org
Subject: Re: Mesos-DNS configuration problem with dockerized web
application
Hi,
portMappings: [
{ containerPort: 8080, hostPort: *80*, servicePort: 9000,
protocol: tcp }
]
will work - you need to specify required port as hostPort
only limitation of this setup is that you wont be able to run multiple
services on single host with same hostPort (port collision)
but for most setups you should be ok with just choosing random/different
ports for different services or ensuring there are more nodes than
requested instances with same port
if you want to use random port - you will need some have logic to query
DNS and parse SRV records and for example setup HA proxy with correctly
assigned ports
this problem can also be solved using SDN (for example flannel/weave -)
assigning each service unique IP address and dont care about port
collisions - but this is not related to MesosDNS - just info :)
2015-07-16 17:58 GMT+02:00 Dvorkin-Contractor, Eugene (CORP)
eugene.dvorkin-contrac...@adp.com:
Hi,
I can’t access my application using mesos-dns. Neither port 8123 nor
8080 responding. I think I miss something in configuration but can’t find
problem myself.
I have a very basic java application that listen on port 8080. I have
created docker image and deployed this application to marathon.
My deployment configuration is following:
$ cat app-slick.json
{
container: {
type: DOCKER,
docker: {
image: edvorkin/slick-swagger:1,
network: BRIDGE,
portMappings: [
{ containerPort: 8080, hostPort: 0, servicePort: 9000,
protocol: tcp }
]
}
},
cmd: java -jar /tmp/spray-slick-swagger-assembly-0.0.2.jar Boot,
id: slick-swagger-demo,
instances: 1,
cpus: 0.1,
mem: 256,
constraints: [
[hostname, UNIQUE]
]
}
Application successfully deployed to 2 nodes and assigned random port
of 31990 and 31000 on each node.
Now I installed and configured Mesos-DNS with config.json
{
zk: zk://172.31.50.58:2181,172.31.50.59:2181,172.31.50.60:2181/mesos,
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 53,
resolvers: [172.31.0.2],
timeout: 5,
email: root.mesos-dns.mesos
}
and I got following:
$ *dig slick-swagger-demo.marathon.mesos*
; DiG 9.9.4-RedHat-9.9.4-18.el7_1.1
slick-swagger-demo.marathon.mesos
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 20376
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;slick-swagger-demo.marathon.mesos. IN A
;; ANSWER SECTION:
slick-swagger-demo.marathon.mesos. 60 IN A 172.31.11.202
slick-swagger-demo.marathon.mesos. 60 IN A 172.31.11.203
;; Query time: 1 msec
;; SERVER: 54.86.164.193#53(54.86.164.193)
;; WHEN: Thu Jul 16 15:23:04 UTC 2015
;; MSG SIZE rcvd: 83
*curl
http://localhost:8123/v1/services/_slick-swagger-demo._tcp.marathon.mesos
http://localhost:8123/v1/services/_slick-swagger-demo._tcp.marathon.mesos
|python -m json.tool*
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
100 289 100 2890 0 1916 0 --:--:-- --:--:-- --:--:--
1926
[
{
host: slick-swagger-demo-15491-s42.marathon.mesos.,
ip: 172.31.11.203,
port: 31990,
service: _slick-swagger-demo._tcp.marathon.mesos
},
{
host: slick-swagger-demo-20495-s43.marathon.mesos.,
ip: 172.31.11.202,
port: 31000,
service: _slick-swagger-demo._tcp.marathon.mesos
}
]
But when I try to access my application using dns name, I can’t get get
response.
curl http://slick-swagger-demo.marathon.mesos:8080
curl: (7) Failed connect to slick-swagger-demo.marathon.mesos:8080;
Connection refused
curl slick-swagger-demo.marathon.mesos:8123
404: Page Not Found
curl slick-swagger-demo.marathon.mesos:31990 – produce desired results,
but that binded to a random port.
How do I configure mapping between random ports
Re: Mesos-DNS configuration problem with dockerized web application
Hi,
portMappings: [
{ containerPort: 8080, hostPort: *80*, servicePort: 9000,
protocol: tcp }
]
will work - you need to specify required port as hostPort
only limitation of this setup is that you wont be able to run multiple
services on single host with same hostPort (port collision)
but for most setups you should be ok with just choosing random/different
ports for different services or ensuring there are more nodes than
requested instances with same port
if you want to use random port - you will need some have logic to query DNS
and parse SRV records and for example setup HA proxy with correctly
assigned ports
this problem can also be solved using SDN (for example flannel/weave -)
assigning each service unique IP address and dont care about port
collisions - but this is not related to MesosDNS - just info :)
2015-07-16 17:58 GMT+02:00 Dvorkin-Contractor, Eugene (CORP)
eugene.dvorkin-contrac...@adp.com:
Hi,
I can’t access my application using mesos-dns. Neither port 8123 nor 8080
responding. I think I miss something in configuration but can’t find
problem myself.
I have a very basic java application that listen on port 8080. I have
created docker image and deployed this application to marathon.
My deployment configuration is following:
$ cat app-slick.json
{
container: {
type: DOCKER,
docker: {
image: edvorkin/slick-swagger:1,
network: BRIDGE,
portMappings: [
{ containerPort: 8080, hostPort: 0, servicePort: 9000,
protocol: tcp }
]
}
},
cmd: java -jar /tmp/spray-slick-swagger-assembly-0.0.2.jar Boot,
id: slick-swagger-demo,
instances: 1,
cpus: 0.1,
mem: 256,
constraints: [
[hostname, UNIQUE]
]
}
Application successfully deployed to 2 nodes and assigned random port of
31990 and 31000 on each node.
Now I installed and configured Mesos-DNS with config.json
{
zk: zk://172.31.50.58:2181,172.31.50.59:2181,172.31.50.60:2181/mesos,
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 53,
resolvers: [172.31.0.2],
timeout: 5,
email: root.mesos-dns.mesos
}
and I got following:
$ *dig slick-swagger-demo.marathon.mesos*
; DiG 9.9.4-RedHat-9.9.4-18.el7_1.1
slick-swagger-demo.marathon.mesos
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 20376
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;slick-swagger-demo.marathon.mesos. IN A
;; ANSWER SECTION:
slick-swagger-demo.marathon.mesos. 60 IN A 172.31.11.202
slick-swagger-demo.marathon.mesos. 60 IN A 172.31.11.203
;; Query time: 1 msec
;; SERVER: 54.86.164.193#53(54.86.164.193)
;; WHEN: Thu Jul 16 15:23:04 UTC 2015
;; MSG SIZE rcvd: 83
*curl
http://localhost:8123/v1/services/_slick-swagger-demo._tcp.marathon.mesos
http://localhost:8123/v1/services/_slick-swagger-demo._tcp.marathon.mesos
|python -m json.tool*
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
100 289 100 2890 0 1916 0 --:--:-- --:--:-- --:--:--
1926
[
{
host: slick-swagger-demo-15491-s42.marathon.mesos.,
ip: 172.31.11.203,
port: 31990,
service: _slick-swagger-demo._tcp.marathon.mesos
},
{
host: slick-swagger-demo-20495-s43.marathon.mesos.,
ip: 172.31.11.202,
port: 31000,
service: _slick-swagger-demo._tcp.marathon.mesos
}
]
But when I try to access my application using dns name, I can’t get get
response.
curl http://slick-swagger-demo.marathon.mesos:8080
curl: (7) Failed connect to slick-swagger-demo.marathon.mesos:8080;
Connection refused
curl slick-swagger-demo.marathon.mesos:8123
404: Page Not Found
curl slick-swagger-demo.marathon.mesos:31990 – produce desired results,
but that binded to a random port.
How do I configure mapping between random ports and my service?
I would like to be able to access my server on port 80 for example
Curl http://slick-swagger-demo.marathon.mesos
Thanks
Eugene
--
This message and any attachments are intended only for the use of the
addressee and may contain information that is privileged and confidential.
If the reader of the message is not the intended recipient or an authorized
representative of the intended recipient, you are hereby notified that any
dissemination of this communication is strictly prohibited. If you have
received this communication in error, notify the sender immediately by
return email and delete the message and any attachments from your system.
mesos-dns
I've just started playing with mesos so excuse me if this is a stupid question. I'm configuring mesos-dns for my very small cluster (initial size) 3 + 3 nodes. I'm planning to use 3 zookeeper nodes combined with mesos masters, chronos, and marathon and mesos-dns. this will be using 3+ nodes as mesos slaves combined with native kafka (not using mesos) using the same zookeepers. I want to use the slave nodes both for kafka and for the service on to on kafka that performs the actual work. (a massive MQTT broker) I looked at the mesos-dns ansible script and realized that is is intended to run as maraton jobs. However I'm inclined to run them on each master node using upstart since I want to use haproxy to find a first level proxy that should live in the mesos cluster (I think I want fixed addresses to dns for that to work). Is there any drawback of that approach (instead of marathon)? best regards svante
Re: mesos-dns
Running via upstart is a fine approach On Thu, Jun 4, 2015 at 5:41 PM, Svante Karlsson svante.karls...@csi.se wrote: I've just started playing with mesos so excuse me if this is a stupid question. I'm configuring mesos-dns for my very small cluster (initial size) 3 + 3 nodes. I'm planning to use 3 zookeeper nodes combined with mesos masters, chronos, and marathon and mesos-dns. this will be using 3+ nodes as mesos slaves combined with native kafka (not using mesos) using the same zookeepers. I want to use the slave nodes both for kafka and for the service on to on kafka that performs the actual work. (a massive MQTT broker) I looked at the mesos-dns ansible script and realized that is is intended to run as maraton jobs. However I'm inclined to run them on each master node using upstart since I want to use haproxy to find a first level proxy that should live in the mesos cluster (I think I want fixed addresses to dns for that to work). Is there any drawback of that approach (instead of marathon)? best regards svante -- James DeFelice 585.241.9488 (voice) 650.649.6071 (fax)
Re: mesos-dns
just put a blog post up on running mesos-dns with docker https://mesosphere.com/blog/2015/06/02/get-mesos-dns-up-and-running-in-under-5-minutes-using-docker/ https://mesosphere.com/blog/2015/06/02/get-mesos-dns-up-and-running-in-under-5-minutes-using-docker/ and upstart is fine. ken On Jun 4, 2015, at 4:41 PM, Svante Karlsson svante.karls...@csi.se wrote: I've just started playing with mesos so excuse me if this is a stupid question. I'm configuring mesos-dns for my very small cluster (initial size) 3 + 3 nodes. I'm planning to use 3 zookeeper nodes combined with mesos masters, chronos, and marathon and mesos-dns. this will be using 3+ nodes as mesos slaves combined with native kafka (not using mesos) using the same zookeepers. I want to use the slave nodes both for kafka and for the service on to on kafka that performs the actual work. (a massive MQTT broker) I looked at the mesos-dns ansible script and realized that is is intended to run as maraton jobs. However I'm inclined to run them on each master node using upstart since I want to use haproxy to find a first level proxy that should live in the mesos cluster (I think I want fixed addresses to dns for that to work). Is there any drawback of that approach (instead of marathon)? best regards svante
RE: Using mesos-dns in an enterprise
Thanks for this... very useful!
From: Christos Kozyrakis [kozyr...@gmail.com]
Sent: 07 April 2015 23:25
To: user@mesos.apache.org
Cc: John Omernik
Subject: Re: Using mesos-dns in an enterprise
This is a great thread, thanks for starting it John.
I will transcode your message into a tutorial on the Mesos-DNS documentation. I
will ping you to take a look and edit as needed (that goes to all of you with
some experience on the topic).
On Thu, Apr 2, 2015 at 5:58 PM, John Omernik
j...@omernik.commailto:j...@omernik.com wrote:
Mesos-dns seems pretty light weight, why not constrain it to a group of 3-5
hosts, and then list all of them as your forwarding resolvers. While not truly
run anywhere, I would imagine with some good node/rack placement you would be
sufficiently HA
On Thursday, April 2, 2015, Tom Arnfeld
t...@duedil.commailto:t...@duedil.com wrote:
We're using a BGP based solution currently to solve the problem of highly
available DNS resolvers.
That might be a route worth taking, and one that could still work via marathon
on top of Mesos.
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046tel:%28%2B44%29%207525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 10:07 PM, John Omernik j...@omernik.com wrote:
True :)
On Thu, Apr 2, 2015 at 3:37 PM, Tom Arnfeld t...@duedil.com wrote:
Last time I checked haproxy didn't support UDP which would be key for mesos-dns.
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046tel:%28%2B44%29%207525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 3:53 PM, John Omernik j...@omernik.com wrote:
That was my first response as well... I work at a bank, and the thought of
changing dns servers on the clients everywhere made me roll my eyes :)
John
On Thu, Apr 2, 2015 at 9:39 AM, Tom Arnfeld t...@duedil.com wrote:
This is great, thanks for sharing!
It's nice to see other members of the community sharing more realistic
implementations of DNS rather than just update your resolv conf and it works
:-)
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046tel:%28%2B44%29%207525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 3:30 PM, John Omernik j...@omernik.com wrote:
Based on my earlier emails about the state of service discovery. I did some
research and a little writeup on how to use mesos-dns as a forward lookup zone
in a enterprise bind installation. I feel this is more secure, and more
comfortable for an enterprise DNS team as opposed to changing the first
resolver on every client that may interact with mesos to be the mesos-dns
server. Please feel free to modify/correct and include this in the mesos-dns
documentation if you feel it's valuable.
Goals/Thought Process
- Run mesos-dns on a non-standard port. (such as 8053). This allows you to run
it as a non-root user.
- While most DNS clients may not understand this (a different port), in an
enterprise, most DNS servers will respect a forward lookup zone with a server
using a different port.
- Setup below for BIND9 allows you to keep all your mesos servers AND clients
in an enterprise pointing their requests at your enterprise DNS server, rather
than mesos-dns.
- This is easier from an enterprise configuration standpoint. Make one change
on your dns servers, rather than adding a resolver on all the clients.
- This is more secure in that you can run mesos-dns as non-root (53 is a
privileged port, 8053 is not) no sudo required
- For more security, you can limit connections to the mesos-dns server to
only your enterprise dns servers. This could help mitigate any unknown
vulnerabilities in mesos-dns.
- This allows you to HA mesos-dns in that you can specify multiple resolvers
for your bind configuration.
Bind9 Config
This was put into my named.conf.local It sets up the .mesos zone and forwards
to mesos dns. All my mesos servers already pointed at this server, therefore no
client changes required.
#192.168.0.100 is my host running mesos DNS
zone mesos {
type forward;
forward only;
forwarders { 192.168.0.100 port 8053; };
};
config.json mesos-dns config file.
I DID specify my internal DNS server in the resolvers (192.168.0.10) however, I
am not sure if I need to do this. Since only requests for .mesos will actually
be sent to mesos-dns.
{
masters: [192.168.0.98:5050http://192.168.0.98:5050],
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 8053,
resolvers: [192.168.0.10],
timeout: 5,
listener: 0.0.0.0,
email: root.mesos-dns.mesos
}
marathon start json
Note the lack of sudo here. I also constrained it to one host for now, but that
could change if needed.
{
cmd: /mapr/brewpot/mesos/mesos-dns/mesos-dns
-config=/mapr/brewpot/mesos/mesos-dns/config.json,
cpus: 1.0,
mem: 1024,
id: mesos-dns,
instances: 1,
constraints: [[hostname, CLUSTER,
hadoopmapr1.brewingintel.comhttp://hadoopmapr1.brewingintel.com]]
}
--
Sent from my iThing
Re: Using mesos-dns in an enterprise
This is a great thread, thanks for starting it John.
I will transcode your message into a tutorial on the Mesos-DNS
documentation. I will ping you to take a look and edit as needed (that goes
to all of you with some experience on the topic).
On Thu, Apr 2, 2015 at 5:58 PM, John Omernik j...@omernik.com wrote:
Mesos-dns seems pretty light weight, why not constrain it to a group of
3-5 hosts, and then list all of them as your forwarding resolvers. While
not truly run anywhere, I would imagine with some good node/rack
placement you would be sufficiently HA
On Thursday, April 2, 2015, Tom Arnfeld t...@duedil.com wrote:
We're using a BGP based solution currently to solve the problem of highly
available DNS resolvers.
That might be a route worth taking, and one that could still work via
marathon on top of Mesos.
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 10:07 PM, John Omernik j...@omernik.com wrote:
True :)
On Thu, Apr 2, 2015 at 3:37 PM, Tom Arnfeld t...@duedil.com wrote:
Last time I checked haproxy didn't support UDP which would be key for
mesos-dns.
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 3:53 PM, John Omernik j...@omernik.com wrote:
That was my first response as well... I work at a bank, and the
thought of changing dns servers on the clients everywhere made me roll my
eyes :)
John
On Thu, Apr 2, 2015 at 9:39 AM, Tom Arnfeld t...@duedil.com wrote:
This is great, thanks for sharing!
It's nice to see other members of the community sharing more
realistic implementations of DNS rather than just update your resolv
conf
and it works :-)
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 3:30 PM, John Omernik j...@omernik.com
wrote:
Based on my earlier emails about the state of service discovery. I
did some research and a little writeup on how to use mesos-dns as a
forward
lookup zone in a enterprise bind installation. I feel this is more
secure,
and more comfortable for an enterprise DNS team as opposed to changing
the
first resolver on every client that may interact with mesos to be the
mesos-dns server. Please feel free to modify/correct and include this
in
the mesos-dns documentation if you feel it's valuable.
Goals/Thought Process
- Run mesos-dns on a non-standard port. (such as 8053). This allows
you to run it as a non-root user.
- While most DNS clients may not understand this (a different port),
in an enterprise, most DNS servers will respect a forward lookup zone
with
a server using a different port.
- Setup below for BIND9 allows you to keep all your mesos servers
AND clients in an enterprise pointing their requests at your enterprise
DNS
server, rather than mesos-dns.
- This is easier from an enterprise configuration standpoint. Make
one change on your dns servers, rather than adding a resolver on all the
clients.
- This is more secure in that you can run mesos-dns as non-root
(53 is a privileged port, 8053 is not) no sudo required
- For more security, you can limit connections to the mesos-dns
server to only your enterprise dns servers. This could help mitigate any
unknown vulnerabilities in mesos-dns.
- This allows you to HA mesos-dns in that you can specify multiple
resolvers for your bind configuration.
Bind9 Config
This was put into my named.conf.local It sets up the .mesos zone and
forwards to mesos dns. All my mesos servers already pointed at this
server,
therefore no client changes required.
#192.168.0.100 is my host running mesos DNS
zone mesos {
type forward;
forward only;
forwarders { 192.168.0.100 port 8053; };
};
config.json mesos-dns config file.
I DID specify my internal DNS server in the resolvers (192.168.0.10)
however, I am not sure if I need to do this. Since only requests for
.mesos will actually be sent to mesos-dns.
{
masters: [192.168.0.98:5050],
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 8053,
resolvers: [192.168.0.10],
timeout: 5,
listener: 0.0.0.0,
email: root.mesos-dns.mesos
}
marathon start json
Note the lack of sudo here. I also constrained it to one host for
now, but that could change if needed.
{
cmd: /mapr/brewpot/mesos/mesos-dns/mesos-dns
-config=/mapr/brewpot/mesos/mesos-dns/config.json,
cpus: 1.0,
mem: 1024,
id: mesos-dns,
instances: 1,
constraints: [[hostname, CLUSTER,
hadoopmapr1.brewingintel.com]]
}
--
Sent from my iThing
--
Christos
Re: Using mesos-dns in an enterprise
True :)
On Thu, Apr 2, 2015 at 3:37 PM, Tom Arnfeld t...@duedil.com wrote:
Last time I checked haproxy didn't support UDP which would be key for
mesos-dns.
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 3:53 PM, John Omernik j...@omernik.com wrote:
That was my first response as well... I work at a bank, and the thought
of changing dns servers on the clients everywhere made me roll my eyes :)
John
On Thu, Apr 2, 2015 at 9:39 AM, Tom Arnfeld t...@duedil.com wrote:
This is great, thanks for sharing!
It's nice to see other members of the community sharing more realistic
implementations of DNS rather than just update your resolv conf and it
works :-)
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 3:30 PM, John Omernik j...@omernik.com wrote:
Based on my earlier emails about the state of service discovery. I did
some research and a little writeup on how to use mesos-dns as a forward
lookup zone in a enterprise bind installation. I feel this is more secure,
and more comfortable for an enterprise DNS team as opposed to changing the
first resolver on every client that may interact with mesos to be the
mesos-dns server. Please feel free to modify/correct and include this in
the mesos-dns documentation if you feel it's valuable.
Goals/Thought Process
- Run mesos-dns on a non-standard port. (such as 8053). This allows
you to run it as a non-root user.
- While most DNS clients may not understand this (a different port), in
an enterprise, most DNS servers will respect a forward lookup zone with a
server using a different port.
- Setup below for BIND9 allows you to keep all your mesos servers AND
clients in an enterprise pointing their requests at your enterprise DNS
server, rather than mesos-dns.
- This is easier from an enterprise configuration standpoint. Make
one change on your dns servers, rather than adding a resolver on all the
clients.
- This is more secure in that you can run mesos-dns as non-root (53
is a privileged port, 8053 is not) no sudo required
- For more security, you can limit connections to the mesos-dns
server to only your enterprise dns servers. This could help mitigate any
unknown vulnerabilities in mesos-dns.
- This allows you to HA mesos-dns in that you can specify multiple
resolvers for your bind configuration.
Bind9 Config
This was put into my named.conf.local It sets up the .mesos zone and
forwards to mesos dns. All my mesos servers already pointed at this server,
therefore no client changes required.
#192.168.0.100 is my host running mesos DNS
zone mesos {
type forward;
forward only;
forwarders { 192.168.0.100 port 8053; };
};
config.json mesos-dns config file.
I DID specify my internal DNS server in the resolvers (192.168.0.10)
however, I am not sure if I need to do this. Since only requests for
.mesos will actually be sent to mesos-dns.
{
masters: [192.168.0.98:5050],
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 8053,
resolvers: [192.168.0.10],
timeout: 5,
listener: 0.0.0.0,
email: root.mesos-dns.mesos
}
marathon start json
Note the lack of sudo here. I also constrained it to one host for now,
but that could change if needed.
{
cmd: /mapr/brewpot/mesos/mesos-dns/mesos-dns
-config=/mapr/brewpot/mesos/mesos-dns/config.json,
cpus: 1.0,
mem: 1024,
id: mesos-dns,
instances: 1,
constraints: [[hostname, CLUSTER, hadoopmapr1.brewingintel.com
]]
}
Re: Using mesos-dns in an enterprise
We're using a BGP based solution currently to solve the problem of highly
available DNS resolvers.
That might be a route worth taking, and one that could still work via marathon
on top of Mesos.
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 10:07 PM, John Omernik j...@omernik.com wrote:
True :)
On Thu, Apr 2, 2015 at 3:37 PM, Tom Arnfeld t...@duedil.com wrote:
Last time I checked haproxy didn't support UDP which would be key for
mesos-dns.
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 3:53 PM, John Omernik j...@omernik.com wrote:
That was my first response as well... I work at a bank, and the thought
of changing dns servers on the clients everywhere made me roll my eyes :)
John
On Thu, Apr 2, 2015 at 9:39 AM, Tom Arnfeld t...@duedil.com wrote:
This is great, thanks for sharing!
It's nice to see other members of the community sharing more realistic
implementations of DNS rather than just update your resolv conf and it
works :-)
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 3:30 PM, John Omernik j...@omernik.com wrote:
Based on my earlier emails about the state of service discovery. I did
some research and a little writeup on how to use mesos-dns as a forward
lookup zone in a enterprise bind installation. I feel this is more secure,
and more comfortable for an enterprise DNS team as opposed to changing the
first resolver on every client that may interact with mesos to be the
mesos-dns server. Please feel free to modify/correct and include this in
the mesos-dns documentation if you feel it's valuable.
Goals/Thought Process
- Run mesos-dns on a non-standard port. (such as 8053). This allows
you to run it as a non-root user.
- While most DNS clients may not understand this (a different port), in
an enterprise, most DNS servers will respect a forward lookup zone with a
server using a different port.
- Setup below for BIND9 allows you to keep all your mesos servers AND
clients in an enterprise pointing their requests at your enterprise DNS
server, rather than mesos-dns.
- This is easier from an enterprise configuration standpoint. Make
one change on your dns servers, rather than adding a resolver on all the
clients.
- This is more secure in that you can run mesos-dns as non-root (53
is a privileged port, 8053 is not) no sudo required
- For more security, you can limit connections to the mesos-dns
server to only your enterprise dns servers. This could help mitigate any
unknown vulnerabilities in mesos-dns.
- This allows you to HA mesos-dns in that you can specify multiple
resolvers for your bind configuration.
Bind9 Config
This was put into my named.conf.local It sets up the .mesos zone and
forwards to mesos dns. All my mesos servers already pointed at this
server,
therefore no client changes required.
#192.168.0.100 is my host running mesos DNS
zone mesos {
type forward;
forward only;
forwarders { 192.168.0.100 port 8053; };
};
config.json mesos-dns config file.
I DID specify my internal DNS server in the resolvers (192.168.0.10)
however, I am not sure if I need to do this. Since only requests for
.mesos will actually be sent to mesos-dns.
{
masters: [192.168.0.98:5050],
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 8053,
resolvers: [192.168.0.10],
timeout: 5,
listener: 0.0.0.0,
email: root.mesos-dns.mesos
}
marathon start json
Note the lack of sudo here. I also constrained it to one host for now,
but that could change if needed.
{
cmd: /mapr/brewpot/mesos/mesos-dns/mesos-dns
-config=/mapr/brewpot/mesos/mesos-dns/config.json,
cpus: 1.0,
mem: 1024,
id: mesos-dns,
instances: 1,
constraints: [[hostname, CLUSTER, hadoopmapr1.brewingintel.com
]]
}
Re: Using mesos-dns in an enterprise
You could also just use keepalived for a vip on each mesos-dns instance
assuming they are in the same lan.
On Thursday, April 2, 2015, Tom Arnfeld t...@duedil.com wrote:
We're using a BGP based solution currently to solve the problem of highly
available DNS resolvers.
That might be a route worth taking, and one that could still work via
marathon on top of Mesos.
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 10:07 PM, John Omernik j...@omernik.com
javascript:_e(%7B%7D,'cvml','j...@omernik.com'); wrote:
True :)
On Thu, Apr 2, 2015 at 3:37 PM, Tom Arnfeld t...@duedil.com
javascript:_e(%7B%7D,'cvml','t...@duedil.com'); wrote:
Last time I checked haproxy didn't support UDP which would be key for
mesos-dns.
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 3:53 PM, John Omernik j...@omernik.com
javascript:_e(%7B%7D,'cvml','j...@omernik.com'); wrote:
That was my first response as well... I work at a bank, and the thought
of changing dns servers on the clients everywhere made me roll my eyes :)
John
On Thu, Apr 2, 2015 at 9:39 AM, Tom Arnfeld t...@duedil.com
javascript:_e(%7B%7D,'cvml','t...@duedil.com'); wrote:
This is great, thanks for sharing!
It's nice to see other members of the community sharing more realistic
implementations of DNS rather than just update your resolv conf and it
works :-)
--
Tom Arnfeld
Developer // DueDil
(+44) 7525940046
25 Christopher Street, London, EC2A 2BS
On Thu, Apr 2, 2015 at 3:30 PM, John Omernik j...@omernik.com
javascript:_e(%7B%7D,'cvml','j...@omernik.com'); wrote:
Based on my earlier emails about the state of service discovery. I
did some research and a little writeup on how to use mesos-dns as a
forward
lookup zone in a enterprise bind installation. I feel this is more
secure,
and more comfortable for an enterprise DNS team as opposed to changing
the
first resolver on every client that may interact with mesos to be the
mesos-dns server. Please feel free to modify/correct and include this in
the mesos-dns documentation if you feel it's valuable.
Goals/Thought Process
- Run mesos-dns on a non-standard port. (such as 8053). This allows
you to run it as a non-root user.
- While most DNS clients may not understand this (a different port),
in an enterprise, most DNS servers will respect a forward lookup zone
with
a server using a different port.
- Setup below for BIND9 allows you to keep all your mesos servers AND
clients in an enterprise pointing their requests at your enterprise DNS
server, rather than mesos-dns.
- This is easier from an enterprise configuration standpoint. Make
one change on your dns servers, rather than adding a resolver on all the
clients.
- This is more secure in that you can run mesos-dns as non-root (53
is a privileged port, 8053 is not) no sudo required
- For more security, you can limit connections to the mesos-dns
server to only your enterprise dns servers. This could help mitigate any
unknown vulnerabilities in mesos-dns.
- This allows you to HA mesos-dns in that you can specify multiple
resolvers for your bind configuration.
Bind9 Config
This was put into my named.conf.local It sets up the .mesos zone and
forwards to mesos dns. All my mesos servers already pointed at this
server,
therefore no client changes required.
#192.168.0.100 is my host running mesos DNS
zone mesos {
type forward;
forward only;
forwarders { 192.168.0.100 port 8053; };
};
config.json mesos-dns config file.
I DID specify my internal DNS server in the resolvers (192.168.0.10)
however, I am not sure if I need to do this. Since only requests for
.mesos will actually be sent to mesos-dns.
{
masters: [192.168.0.98:5050],
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 8053,
resolvers: [192.168.0.10],
timeout: 5,
listener: 0.0.0.0,
email: root.mesos-dns.mesos
}
marathon start json
Note the lack of sudo here. I also constrained it to one host for
now, but that could change if needed.
{
cmd: /mapr/brewpot/mesos/mesos-dns/mesos-dns
-config=/mapr/brewpot/mesos/mesos-dns/config.json,
cpus: 1.0,
mem: 1024,
id: mesos-dns,
instances: 1,
constraints: [[hostname, CLUSTER, hadoopmapr1.brewingintel.com
]]
}
--
Text by Jeff, typos by iPhone
Re: Using mesos-dns in an enterprise
This is roughly how we've integrated consul dns at client sites. Bind
config still needs updating if/when mesos dns relocates.
--sent from my phone
On Apr 2, 2015 10:30 AM, John Omernik j...@omernik.com wrote:
Based on my earlier emails about the state of service discovery. I did
some research and a little writeup on how to use mesos-dns as a forward
lookup zone in a enterprise bind installation. I feel this is more secure,
and more comfortable for an enterprise DNS team as opposed to changing the
first resolver on every client that may interact with mesos to be the
mesos-dns server. Please feel free to modify/correct and include this in
the mesos-dns documentation if you feel it's valuable.
Goals/Thought Process
- Run mesos-dns on a non-standard port. (such as 8053). This allows you
to run it as a non-root user.
- While most DNS clients may not understand this (a different port), in an
enterprise, most DNS servers will respect a forward lookup zone with a
server using a different port.
- Setup below for BIND9 allows you to keep all your mesos servers AND
clients in an enterprise pointing their requests at your enterprise DNS
server, rather than mesos-dns.
- This is easier from an enterprise configuration standpoint. Make one
change on your dns servers, rather than adding a resolver on all the
clients.
- This is more secure in that you can run mesos-dns as non-root (53 is a
privileged port, 8053 is not) no sudo required
- For more security, you can limit connections to the mesos-dns server
to only your enterprise dns servers. This could help mitigate any unknown
vulnerabilities in mesos-dns.
- This allows you to HA mesos-dns in that you can specify multiple
resolvers for your bind configuration.
Bind9 Config
This was put into my named.conf.local It sets up the .mesos zone and
forwards to mesos dns. All my mesos servers already pointed at this server,
therefore no client changes required.
#192.168.0.100 is my host running mesos DNS
zone mesos {
type forward;
forward only;
forwarders { 192.168.0.100 port 8053; };
};
config.json mesos-dns config file.
I DID specify my internal DNS server in the resolvers (192.168.0.10)
however, I am not sure if I need to do this. Since only requests for
.mesos will actually be sent to mesos-dns.
{
masters: [192.168.0.98:5050],
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 8053,
resolvers: [192.168.0.10],
timeout: 5,
listener: 0.0.0.0,
email: root.mesos-dns.mesos
}
marathon start json
Note the lack of sudo here. I also constrained it to one host for now, but
that could change if needed.
{
cmd: /mapr/brewpot/mesos/mesos-dns/mesos-dns
-config=/mapr/brewpot/mesos/mesos-dns/config.json,
cpus: 1.0,
mem: 1024,
id: mesos-dns,
instances: 1,
constraints: [[hostname, CLUSTER, hadoopmapr1.brewingintel.com]]
}
Using mesos-dns in an enterprise
Based on my earlier emails about the state of service discovery. I did
some research and a little writeup on how to use mesos-dns as a forward
lookup zone in a enterprise bind installation. I feel this is more secure,
and more comfortable for an enterprise DNS team as opposed to changing the
first resolver on every client that may interact with mesos to be the
mesos-dns server. Please feel free to modify/correct and include this in
the mesos-dns documentation if you feel it's valuable.
Goals/Thought Process
- Run mesos-dns on a non-standard port. (such as 8053). This allows you to
run it as a non-root user.
- While most DNS clients may not understand this (a different port), in an
enterprise, most DNS servers will respect a forward lookup zone with a
server using a different port.
- Setup below for BIND9 allows you to keep all your mesos servers AND
clients in an enterprise pointing their requests at your enterprise DNS
server, rather than mesos-dns.
- This is easier from an enterprise configuration standpoint. Make one
change on your dns servers, rather than adding a resolver on all the
clients.
- This is more secure in that you can run mesos-dns as non-root (53 is a
privileged port, 8053 is not) no sudo required
- For more security, you can limit connections to the mesos-dns server to
only your enterprise dns servers. This could help mitigate any unknown
vulnerabilities in mesos-dns.
- This allows you to HA mesos-dns in that you can specify multiple
resolvers for your bind configuration.
Bind9 Config
This was put into my named.conf.local It sets up the .mesos zone and
forwards to mesos dns. All my mesos servers already pointed at this server,
therefore no client changes required.
#192.168.0.100 is my host running mesos DNS
zone mesos {
type forward;
forward only;
forwarders { 192.168.0.100 port 8053; };
};
config.json mesos-dns config file.
I DID specify my internal DNS server in the resolvers (192.168.0.10)
however, I am not sure if I need to do this. Since only requests for
.mesos will actually be sent to mesos-dns.
{
masters: [192.168.0.98:5050],
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 8053,
resolvers: [192.168.0.10],
timeout: 5,
listener: 0.0.0.0,
email: root.mesos-dns.mesos
}
marathon start json
Note the lack of sudo here. I also constrained it to one host for now, but
that could change if needed.
{
cmd: /mapr/brewpot/mesos/mesos-dns/mesos-dns
-config=/mapr/brewpot/mesos/mesos-dns/config.json,
cpus: 1.0,
mem: 1024,
id: mesos-dns,
instances: 1,
constraints: [[hostname, CLUSTER, hadoopmapr1.brewingintel.com]]
}
Re: Using mesos-dns in an enterprise
I wonder if you registered mesos-dns's port in marathon like you do
docker containers, if you could use the marathon-ha-proxy bridge in
conjunction to allow it to show up anywhere...
On Thu, Apr 2, 2015 at 11:08 AM, James DeFelice
james.defel...@gmail.com wrote:
This is roughly how we've integrated consul dns at client sites. Bind config
still needs updating if/when mesos dns relocates.
--sent from my phone
On Apr 2, 2015 10:30 AM, John Omernik j...@omernik.com wrote:
Based on my earlier emails about the state of service discovery. I did
some research and a little writeup on how to use mesos-dns as a forward
lookup zone in a enterprise bind installation. I feel this is more secure,
and more comfortable for an enterprise DNS team as opposed to changing the
first resolver on every client that may interact with mesos to be the
mesos-dns server. Please feel free to modify/correct and include this in
the mesos-dns documentation if you feel it's valuable.
Goals/Thought Process
- Run mesos-dns on a non-standard port. (such as 8053). This allows you
to run it as a non-root user.
- While most DNS clients may not understand this (a different port), in an
enterprise, most DNS servers will respect a forward lookup zone with a
server using a different port.
- Setup below for BIND9 allows you to keep all your mesos servers AND
clients in an enterprise pointing their requests at your enterprise DNS
server, rather than mesos-dns.
- This is easier from an enterprise configuration standpoint. Make one
change on your dns servers, rather than adding a resolver on all the
clients.
- This is more secure in that you can run mesos-dns as non-root (53 is a
privileged port, 8053 is not) no sudo required
- For more security, you can limit connections to the mesos-dns server
to only your enterprise dns servers. This could help mitigate any unknown
vulnerabilities in mesos-dns.
- This allows you to HA mesos-dns in that you can specify multiple
resolvers for your bind configuration.
Bind9 Config
This was put into my named.conf.local It sets up the .mesos zone and
forwards to mesos dns. All my mesos servers already pointed at this server,
therefore no client changes required.
#192.168.0.100 is my host running mesos DNS
zone mesos {
type forward;
forward only;
forwarders { 192.168.0.100 port 8053; };
};
config.json mesos-dns config file.
I DID specify my internal DNS server in the resolvers (192.168.0.10)
however, I am not sure if I need to do this. Since only requests for .mesos
will actually be sent to mesos-dns.
{
masters: [192.168.0.98:5050],
refreshSeconds: 60,
ttl: 60,
domain: mesos,
port: 8053,
resolvers: [192.168.0.10],
timeout: 5,
listener: 0.0.0.0,
email: root.mesos-dns.mesos
}
marathon start json
Note the lack of sudo here. I also constrained it to one host for now, but
that could change if needed.
{
cmd: /mapr/brewpot/mesos/mesos-dns/mesos-dns
-config=/mapr/brewpot/mesos/mesos-dns/config.json,
cpus: 1.0,
mem: 1024,
id: mesos-dns,
instances: 1,
constraints: [[hostname, CLUSTER, hadoopmapr1.brewingintel.com]]
}
Re: Zookeeper integration for Mesos-DNS
Aaron, It depends on what you mean however, Mesos-DNS works outside the cluster IMO. It is a bridge for things in the cluster (services launched by mesos)... But at that point it is DNS. Any client in or out of the cluster that can query DNS that leverage the service. Sent from my iPhone On Mar 23, 2015, at 4:25 AM, Aaron Carey aca...@ilm.com wrote: Hey, I don't suppose there is anything like Mesos-DNS but for services/users outside the mesos cluster? So having a service which updates a DNS provider with task port/ips running inside the cluster so that external users are able to find those services? Am I correct in thinking Mesos-DNS only works inside the cluster? Currently we're using consul for this, but I'd be interested if there was some sort of magical plug and play solution? Thanks, Aaron From: Christos Kozyrakis [kozyr...@gmail.com] Sent: 21 March 2015 00:18 To: user@mesos.apache.org Subject: Zookeeper integration for Mesos-DNS Hi everybody, we have updated Mesos-DNS to integrate directly with Zookeeper. Instead of providing Mesos-DNS with a list of masters, you point it to the Zookeeper instances. Meson-DNS will watch Zookeeper to detect the current leading master. So, while the list of Zookeeper instances is configured in a static manner, Mesos masters can be added or removed freely without restarting Mesos-DNS. The integration with Zookeeper forced to switch from -v and -vv as the flags to control verbosity to -v=0 (default), -v=1 (verbose), and -v=2 (very verbose). To reduce complications because of dependencies to other packages, we have also started using godep. Please take a look at the branch https://github.com/mesosphere/mesos-dns/tree/zk and provide us with any feedback on the code or the documentation. Thanks -- Christos
Re: Zookeeper integration for Mesos-DNS
roger that On Mar 23, 2015, at 9:22 AM, Aaron Carey aca...@ilm.com wrote: Thanks Ken, So basically we just need to add mesos-dns to our /etc/resolv.conf on every machine and hey presto auto-service discovery (using DNS)? (Here I mean service discovery to be: hey where is rabbitmq? DNS says: 172.20.121.292:8393 or whatever) Aaron From: Ken Sipe [kens...@gmail.com] Sent: 23 March 2015 14:29 To: user@mesos.apache.org Subject: Re: Zookeeper integration for Mesos-DNS Aaron, Mesos-DNS is a DNS name server + a monitor of mesos-masters. It listens to the mesos-master. If a service is launched by mesos then mesos-dns conjures a service name (app_id + framework_id +.mesos) and associates it to the IP and PORT of the service. Since Mesos-DNS is a name service, it needs to be in your list of name services for service discovery. From a service discovery stand point there is no need to be in the cluster and there is no need to have a dependency on Mesos. Mesos-DNS is not a proxy. It doesn’t provide any special services to clients or services inside the cluster. more detail below. On Mar 23, 2015, at 7:52 AM, Aaron Carey aca...@ilm.com mailto:aca...@ilm.com wrote: As I understood it, it provides a service for containers within the cluster to automatically find each other as it handles their dns calls? The way this is stated this doesn’t seem true.Mesos-DNS is a DNS name server.From a service discovery stand point, It doesn’t do anything different than a standard DNS naming server. However clients outside the cluster will not use the mesos-dns service by default, so won't have knowledge of anything running inside the cluster? This is all dependent on how /etc/resolv.conf is setup. If mesos-dns is in the list… then this is not true. Is there an easy way to set this up to (for example) add records to AWS Route 53 when services get started in the cluster, so other clients can see them? This is outside of Mesos-DNS Good Luck!! Thanks! Aaron From: Ken Sipe [kens...@gmail.com mailto:kens...@gmail.com] Sent: 23 March 2015 13:31 To: user@mesos.apache.org mailto:user@mesos.apache.org Subject: Re: Zookeeper integration for Mesos-DNS Aaron, It depends on what you mean however, Mesos-DNS works outside the cluster IMO. It is a bridge for things in the cluster (services launched by mesos)... But at that point it is DNS. Any client in or out of the cluster that can query DNS that leverage the service. Sent from my iPhone On Mar 23, 2015, at 4:25 AM, Aaron Carey aca...@ilm.com mailto:aca...@ilm.com wrote: Hey, I don't suppose there is anything like Mesos-DNS but for services/users outside the mesos cluster? So having a service which updates a DNS provider with task port/ips running inside the cluster so that external users are able to find those services? Am I correct in thinking Mesos-DNS only works inside the cluster? Currently we're using consul for this, but I'd be interested if there was some sort of magical plug and play solution? Thanks, Aaron From: Christos Kozyrakis [kozyr...@gmail.com mailto:kozyr...@gmail.com] Sent: 21 March 2015 00:18 To: user@mesos.apache.org mailto:user@mesos.apache.org Subject: Zookeeper integration for Mesos-DNS Hi everybody, we have updated Mesos-DNS to integrate directly with Zookeeper. Instead of providing Mesos-DNS with a list of masters, you point it to the Zookeeper instances. Meson-DNS will watch Zookeeper to detect the current leading master. So, while the list of Zookeeper instances is configured in a static manner, Mesos masters can be added or removed freely without restarting Mesos-DNS. The integration with Zookeeper forced to switch from -v and -vv as the flags to control verbosity to -v=0 (default), -v=1 (verbose), and -v=2 (very verbose). To reduce complications because of dependencies to other packages, we have also started using godep. Please take a look at the branch https://github.com/mesosphere/mesos-dns/tree/zk https://github.com/mesosphere/mesos-dns/tree/zk and provide us with any feedback on the code or the documentation. Thanks -- Christos
Re: Zookeeper integration for Mesos-DNS
Aaron, Mesos-DNS is a DNS name server + a monitor of mesos-masters. It listens to the mesos-master. If a service is launched by mesos then mesos-dns conjures a service name (app_id + framework_id +.mesos) and associates it to the IP and PORT of the service. Since Mesos-DNS is a name service, it needs to be in your list of name services for service discovery. From a service discovery stand point there is no need to be in the cluster and there is no need to have a dependency on Mesos. Mesos-DNS is not a proxy. It doesn’t provide any special services to clients or services inside the cluster. more detail below. On Mar 23, 2015, at 7:52 AM, Aaron Carey aca...@ilm.com wrote: As I understood it, it provides a service for containers within the cluster to automatically find each other as it handles their dns calls? The way this is stated this doesn’t seem true.Mesos-DNS is a DNS name server.From a service discovery stand point, It doesn’t do anything different than a standard DNS naming server. However clients outside the cluster will not use the mesos-dns service by default, so won't have knowledge of anything running inside the cluster? This is all dependent on how /etc/resolv.conf is setup. If mesos-dns is in the list… then this is not true. Is there an easy way to set this up to (for example) add records to AWS Route 53 when services get started in the cluster, so other clients can see them? This is outside of Mesos-DNS Good Luck!! Thanks! Aaron From: Ken Sipe [kens...@gmail.com mailto:kens...@gmail.com] Sent: 23 March 2015 13:31 To: user@mesos.apache.org mailto:user@mesos.apache.org Subject: Re: Zookeeper integration for Mesos-DNS Aaron, It depends on what you mean however, Mesos-DNS works outside the cluster IMO. It is a bridge for things in the cluster (services launched by mesos)... But at that point it is DNS. Any client in or out of the cluster that can query DNS that leverage the service. Sent from my iPhone On Mar 23, 2015, at 4:25 AM, Aaron Carey aca...@ilm.com mailto:aca...@ilm.com wrote: Hey, I don't suppose there is anything like Mesos-DNS but for services/users outside the mesos cluster? So having a service which updates a DNS provider with task port/ips running inside the cluster so that external users are able to find those services? Am I correct in thinking Mesos-DNS only works inside the cluster? Currently we're using consul for this, but I'd be interested if there was some sort of magical plug and play solution? Thanks, Aaron From: Christos Kozyrakis [kozyr...@gmail.com mailto:kozyr...@gmail.com] Sent: 21 March 2015 00:18 To: user@mesos.apache.org mailto:user@mesos.apache.org Subject: Zookeeper integration for Mesos-DNS Hi everybody, we have updated Mesos-DNS to integrate directly with Zookeeper. Instead of providing Mesos-DNS with a list of masters, you point it to the Zookeeper instances. Meson-DNS will watch Zookeeper to detect the current leading master. So, while the list of Zookeeper instances is configured in a static manner, Mesos masters can be added or removed freely without restarting Mesos-DNS. The integration with Zookeeper forced to switch from -v and -vv as the flags to control verbosity to -v=0 (default), -v=1 (verbose), and -v=2 (very verbose). To reduce complications because of dependencies to other packages, we have also started using godep. Please take a look at the branch https://github.com/mesosphere/mesos-dns/tree/zk https://github.com/mesosphere/mesos-dns/tree/zk and provide us with any feedback on the code or the documentation. Thanks -- Christos
RE: Zookeeper integration for Mesos-DNS
As I understood it, it provides a service for containers within the cluster to automatically find each other as it handles their dns calls? However clients outside the cluster will not use the mesos-dns service by default, so won't have knowledge of anything running inside the cluster? Is there an easy way to set this up to (for example) add records to AWS Route 53 when services get started in the cluster, so other clients can see them? Thanks! Aaron From: Ken Sipe [kens...@gmail.com] Sent: 23 March 2015 13:31 To: user@mesos.apache.org Subject: Re: Zookeeper integration for Mesos-DNS Aaron, It depends on what you mean however, Mesos-DNS works outside the cluster IMO. It is a bridge for things in the cluster (services launched by mesos)... But at that point it is DNS. Any client in or out of the cluster that can query DNS that leverage the service. Sent from my iPhone On Mar 23, 2015, at 4:25 AM, Aaron Carey aca...@ilm.commailto:aca...@ilm.com wrote: Hey, I don't suppose there is anything like Mesos-DNS but for services/users outside the mesos cluster? So having a service which updates a DNS provider with task port/ips running inside the cluster so that external users are able to find those services? Am I correct in thinking Mesos-DNS only works inside the cluster? Currently we're using consul for this, but I'd be interested if there was some sort of magical plug and play solution? Thanks, Aaron From: Christos Kozyrakis [kozyr...@gmail.commailto:kozyr...@gmail.com] Sent: 21 March 2015 00:18 To: user@mesos.apache.orgmailto:user@mesos.apache.org Subject: Zookeeper integration for Mesos-DNS Hi everybody, we have updated Mesos-DNS to integrate directly with Zookeeper. Instead of providing Mesos-DNS with a list of masters, you point it to the Zookeeper instances. Meson-DNS will watch Zookeeper to detect the current leading master. So, while the list of Zookeeper instances is configured in a static manner, Mesos masters can be added or removed freely without restarting Mesos-DNS. The integration with Zookeeper forced to switch from -v and -vv as the flags to control verbosity to -v=0 (default), -v=1 (verbose), and -v=2 (very verbose). To reduce complications because of dependencies to other packages, we have also started using godep. Please take a look at the branch https://github.com/mesosphere/mesos-dns/tree/zk and provide us with any feedback on the code or the documentation. Thanks -- Christos
RE: Zookeeper integration for Mesos-DNS
lovely, thanks! From: craig w [codecr...@gmail.com] Sent: 23 March 2015 15:35 To: user@mesos.apache.org Subject: Re: Zookeeper integration for Mesos-DNS Keep in mind DNS will give you the ipaddress of the host, so rabbitmq.marathon.mesos will resolve to some IP address. Do get port information you have to query mesos-dns for its SRV records. On Mon, Mar 23, 2015 at 11:29 AM, Ken Sipe kens...@gmail.commailto:kens...@gmail.com wrote: roger that On Mar 23, 2015, at 9:22 AM, Aaron Carey aca...@ilm.commailto:aca...@ilm.com wrote: Thanks Ken, So basically we just need to add mesos-dns to our /etc/resolv.conf on every machine and hey presto auto-service discovery (using DNS)? (Here I mean service discovery to be: hey where is rabbitmq? DNS says: 172.20.121.292:8393 or whatever) Aaron From: Ken Sipe [kens...@gmail.commailto:kens...@gmail.com] Sent: 23 March 2015 14:29 To: user@mesos.apache.orgmailto:user@mesos.apache.org Subject: Re: Zookeeper integration for Mesos-DNS Aaron, Mesos-DNS is a DNS name server + a monitor of mesos-masters. It listens to the mesos-master. If a service is launched by mesos then mesos-dns conjures a service name (app_id + framework_id +.mesos) and associates it to the IP and PORT of the service. Since Mesos-DNS is a name service, it needs to be in your list of name services for service discovery. From a service discovery stand point there is no need to be in the cluster and there is no need to have a dependency on Mesos. Mesos-DNS is not a proxy. It doesn’t provide any special services to clients or services inside the cluster. more detail below. On Mar 23, 2015, at 7:52 AM, Aaron Carey aca...@ilm.commailto:aca...@ilm.com wrote: As I understood it, it provides a service for containers within the cluster to automatically find each other as it handles their dns calls? The way this is stated this doesn’t seem true.Mesos-DNS is a DNS name server.From a service discovery stand point, It doesn’t do anything different than a standard DNS naming server. However clients outside the cluster will not use the mesos-dns service by default, so won't have knowledge of anything running inside the cluster? This is all dependent on how /etc/resolv.conf is setup. If mesos-dns is in the list… then this is not true. Is there an easy way to set this up to (for example) add records to AWS Route 53 when services get started in the cluster, so other clients can see them? This is outside of Mesos-DNS Good Luck!! Thanks! Aaron From: Ken Sipe [kens...@gmail.commailto:kens...@gmail.com] Sent: 23 March 2015 13:31 To: user@mesos.apache.orgmailto:user@mesos.apache.org Subject: Re: Zookeeper integration for Mesos-DNS Aaron, It depends on what you mean however, Mesos-DNS works outside the cluster IMO. It is a bridge for things in the cluster (services launched by mesos)... But at that point it is DNS. Any client in or out of the cluster that can query DNS that leverage the service. Sent from my iPhone On Mar 23, 2015, at 4:25 AM, Aaron Carey aca...@ilm.commailto:aca...@ilm.com wrote: Hey, I don't suppose there is anything like Mesos-DNS but for services/users outside the mesos cluster? So having a service which updates a DNS provider with task port/ips running inside the cluster so that external users are able to find those services? Am I correct in thinking Mesos-DNS only works inside the cluster? Currently we're using consul for this, but I'd be interested if there was some sort of magical plug and play solution? Thanks, Aaron From: Christos Kozyrakis [kozyr...@gmail.commailto:kozyr...@gmail.com] Sent: 21 March 2015 00:18 To: user@mesos.apache.orgmailto:user@mesos.apache.org Subject: Zookeeper integration for Mesos-DNS Hi everybody, we have updated Mesos-DNS to integrate directly with Zookeeper. Instead of providing Mesos-DNS with a list of masters, you point it to the Zookeeper instances. Meson-DNS will watch Zookeeper to detect the current leading master. So, while the list of Zookeeper instances is configured in a static manner, Mesos masters can be added or removed freely without restarting Mesos-DNS. The integration with Zookeeper forced to switch from -v and -vv as the flags to control verbosity to -v=0 (default), -v=1 (verbose), and -v=2 (very verbose). To reduce complications because of dependencies to other packages, we have also started using godep. Please take a look at the branch https://github.com/mesosphere/mesos-dns/tree/zk and provide us with any feedback on the code or the documentation. Thanks -- Christos -- https://github.com/mindscratch https://www.google.com/+CraigWickesser https://twitter.com/mind_scratch https://twitter.com/craig_links
RE: Zookeeper integration for Mesos-DNS
Hey, I don't suppose there is anything like Mesos-DNS but for services/users outside the mesos cluster? So having a service which updates a DNS provider with task port/ips running inside the cluster so that external users are able to find those services? Am I correct in thinking Mesos-DNS only works inside the cluster? Currently we're using consul for this, but I'd be interested if there was some sort of magical plug and play solution? Thanks, Aaron From: Christos Kozyrakis [kozyr...@gmail.com] Sent: 21 March 2015 00:18 To: user@mesos.apache.org Subject: Zookeeper integration for Mesos-DNS Hi everybody, we have updated Mesos-DNS to integrate directly with Zookeeper. Instead of providing Mesos-DNS with a list of masters, you point it to the Zookeeper instances. Meson-DNS will watch Zookeeper to detect the current leading master. So, while the list of Zookeeper instances is configured in a static manner, Mesos masters can be added or removed freely without restarting Mesos-DNS. The integration with Zookeeper forced to switch from -v and -vv as the flags to control verbosity to -v=0 (default), -v=1 (verbose), and -v=2 (very verbose). To reduce complications because of dependencies to other packages, we have also started using godep. Please take a look at the branch https://github.com/mesosphere/mesos-dns/tree/zk and provide us with any feedback on the code or the documentation. Thanks -- Christos
Re: Zookeeper integration for Mesos-DNS
Hi, I have a question. If mesos-dns have a public ip for other application which not run in mesos? For example, we start a kafka in mesos. For other applications which not running in mesos, we use the ip as kafka config in application. So if mesos-dns have a publich ip, we could use the custom host name as kafka config after we set the dns of application to mesos dns. On Sat, Mar 21, 2015 at 8:18 AM, Christos Kozyrakis kozyr...@gmail.com wrote: Hi everybody, we have updated Mesos-DNS to integrate directly with Zookeeper. Instead of providing Mesos-DNS with a list of masters, you point it to the Zookeeper instances. Meson-DNS will watch Zookeeper to detect the current leading master. So, while the list of Zookeeper instances is configured in a static manner, Mesos masters can be added or removed freely without restarting Mesos-DNS. The integration with Zookeeper forced to switch from -v and -vv as the flags to control verbosity to -v=0 (default), -v=1 (verbose), and -v=2 (very verbose). To reduce complications because of dependencies to other packages, we have also started using godep. Please take a look at the branch https://github.com/mesosphere/mesos-dns/tree/zk and provide us with any feedback on the code or the documentation. Thanks -- Christos -- Best Regards, Haosdent Huang
Zookeeper integration for Mesos-DNS
Hi everybody, we have updated Mesos-DNS to integrate directly with Zookeeper. Instead of providing Mesos-DNS with a list of masters, you point it to the Zookeeper instances. Meson-DNS will watch Zookeeper to detect the current leading master. So, while the list of Zookeeper instances is configured in a static manner, Mesos masters can be added or removed freely without restarting Mesos-DNS. The integration with Zookeeper forced to switch from -v and -vv as the flags to control verbosity to -v=0 (default), -v=1 (verbose), and -v=2 (very verbose). To reduce complications because of dependencies to other packages, we have also started using godep. Please take a look at the branch https://github.com/mesosphere/mesos-dns/tree/zk and provide us with any feedback on the code or the documentation. Thanks -- Christos
Re: Mesos-DNS
Hi Anirudha, we are currently using mesos-dns and latest version compiles just fine (ubuntu 14.04, go 1.2.1). 2015-02-24 18:36 GMT+01:00 Ken Sipe kens...@gmail.com: Anirudha, Did you follow: http://mesosphere.github.io/mesos-dns/docs/ ? the build should work according to the build instructions. ken On Feb 24, 2015, at 11:31 AM, Anirudha Jadhav aniru...@nyu.edu wrote: Whats the plan for mesos DNS? The dns lib is not even released. even the build fails with syntax errors. is there a particular way to get this working? -- Anirudha -- sudo go build -o mesos-dns # github.com/miekg/dns /usr/lib/go/src/pkg/github.com/miekg/dns/msg.go:1936: syntax error: unexpected :, expecting ] /usr/lib/go/src/pkg/github.com/miekg/dns/msg.go:1945: syntax error: unexpected :, expecting ] /usr/lib/go/src/pkg/github.com/miekg/dns/msg.go:1954: syntax error: unexpected :, expecting ]
Mesos-DNS
Whats the plan for mesos DNS? The dns lib is not even released. even the build fails with syntax errors. is there a particular way to get this working? -- Anirudha -- sudo go build -o mesos-dns # github.com/miekg/dns /usr/lib/go/src/pkg/github.com/miekg/dns/msg.go:1936: syntax error: unexpected :, expecting ] /usr/lib/go/src/pkg/github.com/miekg/dns/msg.go:1945: syntax error: unexpected :, expecting ] /usr/lib/go/src/pkg/github.com/miekg/dns/msg.go:1954: syntax error: unexpected :, expecting ]
Re: Mesos-DNS
Anirudha, Did you follow: http://mesosphere.github.io/mesos-dns/docs/ http://mesosphere.github.io/mesos-dns/docs/ ? the build should work according to the build instructions. ken On Feb 24, 2015, at 11:31 AM, Anirudha Jadhav aniru...@nyu.edu wrote: Whats the plan for mesos DNS? The dns lib is not even released. even the build fails with syntax errors. is there a particular way to get this working? -- Anirudha -- sudo go build -o mesos-dns # github.com/miekg/dns http://github.com/miekg/dns /usr/lib/go/src/pkg/github.com/miekg/dns/msg.go:1936 http://github.com/miekg/dns/msg.go:1936: syntax error: unexpected :, expecting ] /usr/lib/go/src/pkg/github.com/miekg/dns/msg.go:1945 http://github.com/miekg/dns/msg.go:1945: syntax error: unexpected :, expecting ] /usr/lib/go/src/pkg/github.com/miekg/dns/msg.go:1954 http://github.com/miekg/dns/msg.go:1954: syntax error: unexpected :, expecting ]
Re: Mesos-DNS
sounds good, tried debugging again, I had the golang installed from apt-get which got an older version of GO. All is good now. is there a timeline for this to be released. Happy to see this is an active project! -Ani On Tue, Feb 24, 2015 at 12:43 PM, Ondrej Smola ondrej.sm...@gmail.com wrote: Hi Anirudha, we are currently using mesos-dns and latest version compiles just fine (ubuntu 14.04, go 1.2.1). 2015-02-24 18:36 GMT+01:00 Ken Sipe kens...@gmail.com: Anirudha, Did you follow: http://mesosphere.github.io/mesos-dns/docs/ ? the build should work according to the build instructions. ken On Feb 24, 2015, at 11:31 AM, Anirudha Jadhav aniru...@nyu.edu wrote: Whats the plan for mesos DNS? The dns lib is not even released. even the build fails with syntax errors. is there a particular way to get this working? -- Anirudha -- sudo go build -o mesos-dns # github.com/miekg/dns /usr/lib/go/src/pkg/github.com/miekg/dns/msg.go:1936: syntax error: unexpected :, expecting ] /usr/lib/go/src/pkg/github.com/miekg/dns/msg.go:1945: syntax error: unexpected :, expecting ] /usr/lib/go/src/pkg/github.com/miekg/dns/msg.go:1954: syntax error: unexpected :, expecting ] -- Anirudha P. Jadhav
Re: can mesos-dns + mesos + docker emulate kubernetes' style of service discovery?
iirc i just used netstat from a dash script (in the docker container) to get the gateway address, or used containers with --net=host, as appropriate :c On 24 Jan 2015, at 20:58, Gallagher Polyn gallagher.po...@gmail.com wrote: On Thu, Jan 22, 2015 at 1:05 PM, craig mcmillan mccraigmccr...@gmail.com wrote: we use the HAProxy configurator script bundled with marathon to bind applications to ports : https://github.com/mesosphere/marathon/blob/master/bin/ haproxy-marathon-bridge HAProxy runs on every mesos slave and each marathon app is then available on every slave at the port(s) declared in the marathon API on localhost (or the docker container gateway host) Given the foregoing, can mesos-dns + mesos (possibly, mesosphere’s marathon) + docker be configured to emulate Kubernetes’ style of service discovery, i.e., no responsibility for DNS resolution in an application consuming other services via TCP? Craig, I now see at least advantage for mesos-dns in the context you introduced in your comment: responsibilities for configuring a standard docker container gateway host or handling the docker container gateway host's resolution in client code can be replaced by mesos-dns. Maybe no big deal, especially if you recommend an easy approach to making the docker container gateway host visible. G
Re: can mesos-dns + mesos + docker emulate kubernetes' style of service discovery?
On Thu, Jan 22, 2015 at 1:05 PM, craig mcmillan mccraigmccr...@gmail.com wrote: we use the HAProxy configurator script bundled with marathon to bind applications to ports : https://github.com/mesosphere/marathon/blob/master/bin/ haproxy-marathon-bridge HAProxy runs on every mesos slave and each marathon app is then available on every slave at the port(s) declared in the marathon API on localhost (or the docker container gateway host) Given the foregoing, can mesos-dns + mesos (possibly, mesosphere’s marathon) + docker be configured to emulate Kubernetes’ style of service discovery, i.e., no responsibility for DNS resolution in an application consuming other services via TCP? Craig, I now see at least advantage for mesos-dns in the context you introduced in your comment: responsibilities for configuring a standard docker container gateway host or handling the docker container gateway host's resolution in client code can be replaced by mesos-dns. Maybe no big deal, especially if you recommend an easy approach to making the docker container gateway host visible. G
Re: can mesos-dns + mesos + docker emulate kubernetes' style of service discovery?
we use the HAProxy configurator script bundled with marathon to bind applications to ports : https://github.com/mesosphere/marathon/blob/master/bin/ haproxy-marathon-bridge Given the foregoing, can mesos-dns + mesos (possibly, mesosphere’s marathon) + docker be configured to emulate Kubernetes’ style of service discovery, i.e., no responsibility for DNS resolution in an application consuming other services via TCP? Thanks Craig. I will try that approach, which I see documented here: mesosphere.com/docs/getting-started/service-discovery. In light of your response, and direction to an approach that predates mesos-dns, it will need to consider what, if any, part mesos-dns has for my goal. Directly, it was progrium.com/blog/2014/09/10/automatic-docker-service-announcement-with-registrator and philzim.com/2014/11/12/service-discovery-orchestration-with-mesos-and-consul that set my expectation that consul could now be replaced with mesos-dns in mesos/marathon clusters. G
can mesos-dns + mesos + docker emulate kubernetes' style of service discovery?
Hi, My goal has been to develop multi-container docker applications locally and expect their seamless introduction to production environments (wow.) I have done a POC for my goal with fig and Kubernetes, and I enjoy that I can depend on standard service ip/port environment variables to be present. (Similarly, I see that efforts resembling Jeff Lindsay’s approaches with docker + consul also rely on standard ip/port environment variables.) Given the foregoing, can mesos-dns + mesos (possibly, mesosphere’s marathon) + docker be configured to emulate Kubernetes’ style of service discovery, i.e., no responsibility for DNS resolution in an application consuming other services via TCP? Thanks, Gallagher
