Marathon-LB Server Entries don't consider ip-per-container tasks

[ozdanborne]

Since v0.14.0, Marathon has supported launching tasks with their own uniquely addressable ipAddress [0] [1].

Mesos-dns has been updated to check for this information and generate records which take this into account [2]. I'm opening this issue to suggest that Marathon-lb should too.

To expand on what a "relevant record" refers to - the current marathon-lb implementation creates the following mapping for docker bridge tasks:
<marathon-lb-ip>:<servicePort> ➡️ <agent-ip>:<hostPort> ➡️ <container-ip>:<containerPort>

IP-per-container means that the container is routable directly from Marathon-lb. So we can replace the middle entry with the container directly:
<marathon-lb-ip>:<servicePort> ➡️ <container-ip>:<discoveryPort>

(I use docker bridge tasks as an example, but the Mesos task implementation should similarly map directly to the task's ip and port).

The implementation should mirror the one used in the linked mesos-dns PR:

• The presence of the ipAddress field should trigger whether this type of entry is created or not.
• We no longer forward requests to the agent-ip, opting instead for the task's IP which is stored in app['tasks']['ipAddresses'][0]['ipAddress'].
  • This field is in a list, but marathon currently only supports 1 ip address per container. So we can always grab the first entry
• We no longer forward to the host port, opting instead to use the container's service port which is specified in app['discovery']['ports'] (possibly defaulting to 80)

I'm going to close #122 in favor of this issue, as failing design it properly resulted in a fundamentally incorrect implementation. (Marathon restricts tasks which launch with ip-per-container from also specifiying portmappings.)