Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: Links: Upgrading the network model #7467
This is a two part proposal. The other portion is at #7468.
Links currently do not satisfy the needs of users for a couple of reasons:
These subjects will be addressed:
Fixating containers to resources
We should guarantee that:
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 will be solved in two fashions. Both are subject to further discussion.
Not a fan of swapping ip's of existing veths and the ARP issues that would ensue.
Seems the most flexible and understandable for admins, but feels like the 5 min fix for a problem that needs a longer-term solution.
This seems like the cleanest implementation with the most long-term appeal. Do we have a sense for how feasible this really is?
Not sure I understand this; currently, I'm able to name a link (e.g.
If this is reloaded with the container-id of the linked container, how would I use that (without using additional service-discovery software)?
Sorry, that was tacked on at the end and in retrospect it probably shouldn’t be — it’s more related to the links UI (which was split out from this proposal) than this.
I’ll retool in a few minutes here.
@gabrtv @crosbymichael and I worked out the details and think the veth move should be feasible, but we're probably going to have to tear up a bit of docker to accomplish it. He gave me some sample code to chew on and I'm fairly confident we'll be able to do this.
The trick is to orchestrate it with named network namespaces as opposed to PID namespaces (which is what docker and libcontainer do currently). Then they should be portable. I'm still a little hazy on implementation but that should be resolved in a few days. I just need some time to play.
This was referenced
Aug 13, 2014
Minor remark though:
I would not free up IP addresses when the address space is exhausted. I would rather require the user to explicitly clean up old containers. I understand that it could be an annoyance, but it makes me feel uncomfortable for two reasons:
Just my 2c.
Other than that, everything else is +1 +1 +1 :-)
I agree it is surprising. I’ll bring it up with the powers that be.
I'd prefer to avoid having to go "looking for" info like this. Today we have tcp and udp, if a 3rd pops up then we have to modify code (hard coded) to search for that env var too. If its all in one list then we only need to grab one env var and parse and we don't need to presume any protocols at all - we just parse it. As long as its always of the form #/proto I don't see the issue in parsing.
Adding the info we're trying to "discover" into the env name is part of the issue I have with our current solution. I feels like you have to already know what the answer is in order to find what you're looking for - kind of silly. That's why I proposed: #8515
Keep in mind usecases where the code doing the "discovery" know nothing - and assume all it might be doing is displaying what it discovers (via some kind of "inspect" op). In those cases it shouldn't really need to have a list of protocols - it should discover those too and having the protocol in the name would make that harder if not impossible.
I don't really foresee us adding a new layer 4 protocol, but I suppose anything's possible. :)
Let's not over-architect this. I need to think about the rest of your message, but I'm not sure what the problem is here if you know the link name:
Is not that complicated.