Re: Mesos (and Marathon) port mapping

[Thomas HUMMEL <th...@pasteur.fr>]

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

Re: Mesos (and Marathon) port mapping

[Thomas HUMMEL <th...@pasteur.fr>]

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
>
>