This is a two part proposal. The other portion is at #7468.

Problem

Links currently do not satisfy the needs of users for a couple of reasons:

• service discovery suffers from the static nature of linking
• links are volatile. ip addresses, port mappings, link names can change as the result of manipulating a link, and other containers are not notified of these changes nor can they trivially deal with these issues.

Solution:

These subjects will be addressed:

• fixating containers to resources
• essential service discovery changes

Fixating containers to resources

We should guarantee that:

• IP addresses should not change between specific container invocations. A container is assigned a specific IP address that will not change until the container is removed, or if stopped and the existing address space is exhausted (in least recently used order of stopped containers).
• Likewise, the above should apply to external port mappings.
• Changing a link should:
  • retarget the port mappings
  • retarget the IP address(es)
  • rewrite the hosts files (see more on service discovery below) for all linked resources with updated content
  • Strategies for retargeting (only one will be used for now):
    1. moving the veth to a new network namespace for the target container (via ip link set) from the host, should incur no arp issues. This method still needs to be tested but should provide great failover benefits that we wouldn’t get with ip address reassignment.
    2. reassign the ip to the veth in the target container. This has some arp issues but may be significantly less surprising or complicated to end-users digging through the links abstraction.
    3. Use an iptables facade to mimic a higher level network that links containers. This would be the point of reference, making retargeting these addresses easily. This would use another internal subnet but is rather flexible.

Service Discovery Changes

Service discovery currently relies on two methods of propagating links information: the environment and hosts files. Since the environment is essentially static, and will become outdated, the solution is to rely on hosts files only. A future proposal will bring DNS support to this scheme.

As mentioned above, global rewriting of hosts files will be necessary. This should be done at link change time, unless the container is started with --link.

Port Discovery

Port discovery will be solved in two fashions. Both are subject to further discussion.

• The environment will provide DOCKER_LINK_PORT_${link_name}. The value will be a comma separated list of ports.
• The environment will provide SRV records to be queried with DNS. The record format will be _${link_name}._${proto} and will respond with multiple port -> A mappings.

Tickets Resolved:

#5186
#2733
#3285
#3155
#2658
#2588 (I think)