Hello,
sorry to insist, is the understanding below correct ? I'm really not sure.
I understand that network/portmapping isolator is using disjoint port
ranges to multiplex traffic into the same ports into containers but I'm
not really sure if we're talking about ephemeral or non-ephemeral ports
here neither if I correctly understand what kind of port is for what
kind of use.
About the direct mapping : what in the container is listening to the
mapped port ? How ?
Also what kind of this ephemeral vs non-ephermeral port is called a
hostPort in Marathon ?
Here's my initial understanding :
Thanks.
On 04/05/2017 12:23 PM, Thomas HUMMEL wrote:
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
