Ok, thanks.
So if I wrap my head around all of this and try to answer my original
question I come up with the following understanding :
- servicePorts a a Marathon only concept
- port mapping isolator is not compatible with docker containerizer
- port mapping isolator is useful when you cannot afford one ip / container
- port mapping isolator uses *ephemeral* ports to multiplex traffic into
containers
the *ephemeral* port range is divided into *disjoint* subsets of
*contiguous* ports, each one affected to one container with a direct
mapping hostport <-> containerPort.
- non-ephemeral ports are affected to framework as a resource. So
containers have *disjoint* sets of them but *not in a contiguous* range
- the default port range offered by a slave is [31000-32000] : those are
*non-ephemeral* ports and is not related to the activation or non
activation of the port-mapping isolator
- with docker containerizer in HOST mode, Marathon framework is offered
such a port (in the [31000-32000] range and shows it in the GUI, but the
app can bind to any different hostport *not in that range* (ex: 9090).
In BRIDGE mode, the Marathon so-called 'hostPort' has to be in that
range (why is that ?)
I am right this time ? ;-)
Thanks
--
TH
