Add support for Docker links

[ekristen]

resolves #21

[ekristen]

also fixes an issue that allows maestro-ng to find a container that has been linked multiple times, whereby its original name is most likely not in the 0 index of c['Names'] anymore

[mpetazzoni]

Thanks.

I think this needs a bit more design though and brings a broader discussion about what environment variables Maestro places in the containers.

Docker links only work when the containers are on the same host. This syntax would make you believe it's possible to link arbitrary containers and people will not understand why it doesn't work.

I'm open to suggestions though, and for example we can make Maestro generate both the current environment variables and ones that match what are expected with links.

There is still the problem of -icc=false. Maestro doesn't really care because it doesn't rely on any of the container's private addresses (the _HOST variables are always the external address of the target container) so even with no inter-container communication you can still reach what you need by going outside of the "Docker network".

[ekristen]

Fair point -- I think that can be mitigated with some better documentation which I can fix on the pull request. Also there are link ambassadors to facilitate cross host linking, that can be talked about and linked to in the documentation. If someone wanted to setup cross host links, they could just configure an ambassador in the yaml file. Check back soon, I'll update the PR with better docs if you are good with that.

Thanks for the app, works great.

[fcoelho]

For containers running on the same host, what I'd really like to see is environment variables that exposed the containers IP address (172.17.0.5 for example, which you get using --link directly) but with the maestro naming scheme, without the need to use _6379_TCP_ for every environment variable you get. Having to specify the port number (instead of a port name) in the environment variable name kinda defeats the purpose of it.

But as mpetazzoni said, there's still the problem of people trying to use links for containers in different hosts. I guess maestro could perform a check before actually running anything to see if there are no containers (and/or services?) in different hosts trying to access each other using links.

[marfillaster]

Maybe use ambassador instead?
http://docs.docker.io/use/ambassador_pattern_linking/

[ekristen]

I still thing that --link should be support directly. Not supporting it just seems a giant waste.

Using Ambassador for multi-server links is not a bad idea, that is what it was designed for, but maestro would have to be able to control the ambassadors behind the scenes.

[deas]

I am with ekristen and think it is important to have maestro support the link feature. Sure, it would be best to have it even transparent, but for now I think there is nothing wrong with special same-host features as long as it is made very clear so people do not get wrong expectations.

[ekristen]

So this idea just going to get canned? @deas my fork has this support if you want it.

[nordicdyno]

I have container prepared for using with Docker link and I don't want rebuild it, just because maestro doesn't want docker links support. (just my thought)

[mpetazzoni]

That's actually a pretty simple pull request, I have no objection. I'll bring this in.

[mpetazzoni]

In db76fdc