Can marathoner handle difference marathon instance?

[sivaramsk]

Say I have a multiple marathon instances running in same hosts but in different port number - can marathoner be able to handle this? Instance 1 - port 8082 Instance 2 - port 8083 I want the haproxy.cfg to have the entries of applications from both the instances. This is a valid case as multiple instances can be run for individual users.

[bobrik]

You should run separate updater-listener chains for each marathon. If ports do not intersect, it is possible to run two listeners with different updaters on the same host. Makes sense?

[sivaramsk]

Ports normally should not intersect, but nothing prevents an user to define same port in different marathon instance. If ports intersect, most likely the second listener would keep restarting. If I pass the below parameters to marathon, I should be able to avoid port intersection right?

--local_port_max (Optional. Default: 20000): Max port number to use when assigning ports to apps. --local_port_min (Optional. Default: 10000): Min port number to use when assigning ports to apps.

[bobrik]

local_port_min and local_port_max do not prevent setting ports to the value that is out of range. Maybe it's a bug in marathon, @kolloch?

[sivaramsk]

I use a modified marathon-haproxy-bridge currently for this scenario. It can query the multiple marathons, and use a hash map to avoid adding overlapping port. Does the listener assumes all the ports from marathon to be unique?

[bobrik]

Listener only does what updater says, updated only does what marathon says. Only one marathon cluster is supported.

To safely support multiple marathon clusters you have to restrict port ranges, they should not overlap. I think it's better to have this restriction in marathon itself.

[kolloch]

Hi @bobrik, the documentation should be improved. --local_port_min and --local_port_max specify the range in which global service ports are assigned dynamically. Their names aren't really good.

So if you specify a service port when launching the app, Marathon just checks that this port is unique.

I actually think that is a nice behavior, since you do not want Marathon to assign ports dynamically that you want to use for static assignments.

[bobrik]

@kolloch thanks, that makes sense.

@sivaramsk I think the best way for you is to check port ranges before you deploy apps on marathon to enforce uniqueness.