According to the marathon documentation:
servicePort: when creating a new application in a marathon (via the REST API or the front end), you can assign one or more service ports to it. You can specify all valid port numbers as service ports, or you can use 0 to indicate that Marathon should automatically assign free maintenance ports to the application. If you choose your own service port, you must make sure that it is unique in all of your applications.
Let me tell you more about this in the light of the two main network configurations for the marathon, providing some information about them while I am on it.
Host mode
Use : default option for Docker applications, only for applications without dockers
In this configuration, your application will communicate directly with the host ports.
Without using service ports
You can ask Marathon to provide you, say, any two ports from the host, the same thing that you want to submit to your application. There are two ways in the application configuration file:
"ports": [ 0, 0 ],
or
"portDefinitions": [ {"port": 0}, {"port": 0} ],
By doing this, Marathon will reserve two ports from the range of available ports and assign them to the environment variables PORT1
and PORT1
.
Therefore, it is very simple to call them directly in the Dockerfile
:
CMD ./launch.sh --listen-on $PORT1 --monitor-on $PORT2
or in the cmd
definition in your Marathon configuration:
"cmd": "./launch.sh --listen-on $PORT1 --monitor-on $PORT2"
Using service ports
Suppose you run your application on multiple hosts (multiple instances are running), and you want to be able to connect to your application on any host in a specific port. That is, when service ports enter the port.
Writing the configuration file:
"ports": [ 3000, 3001 ],
or
"portDefinitions": [ {"port": 3000}, {"port": 3001} ],
... The marathon will STILL assign random ports on the host, it will STILL assign them to the environment variables PORT1
and PORT1
, and it will also reserve ports 3000 and 3001 for you.
You need to use the service discovery mechanism to route traffic from these service ports to $PORT1
and $PORT2
.
You can make the service ports equal to the host ports (for example, if you want to avoid the service discovery mechanism) and have consistent ports for your application on the hosts. You can do this by adding "requirePorts": true
after the port specification.
The caveat here is that Marathon will only be able to plan your application on hosts that have these ports.
Bridge mode
Use : Docker apps only
In this configuration, several specified container ports are mapped to host ports.
Without using service ports
In this mode, you do not use the "ports" or "portDefinitions" directives; instead, you use "portMappings". By doing so, you are effectively telling Docker to map traffic from specific container ports to hosts and vice versa.
You can map container ports to host ports by specifying:
"portMappings": [ { "containerPort": 80, "hostPort": 0, "protocol": "tcp"}, { "containerPort": 443, "hostPort": 0, "protocol": "tcp"} ]
In this case:
- By setting hostPort
to 0, it again selects a random port from the available port range. Again, these ports are assigned to PORT1
and PORT1
env, respectively.
- Setting containerPort
to 0 will make it equal to hostPort
.
Using service ports
As before, you can enable service ports, which will be negotiated for your application through hosts, specifying them in your configuration as follows:
"portMappings": [ { "containerPort": 80, "hostPort": 0, "protocol": "tcp", "servicePort": 3000}, { "containerPort": 443, "hostPort": 0, "protocol": "tcp", "servicePort": 3001} ]
Once again, you need to use the service discovery mechanism to route traffic from these service ports to $PORT1
and $PORT2
.
For more information see
Marathon Port: https://mesosphere.imtqy.com/marathon/docs/ports.html
Docker Connection Mode: http://www.dasblinkenlichten.com/docker-networking-101-host-mode/
Docker Bridge Mode: http://www.dasblinkenlichten.com/docker-networking-101/