Kitematic: Feature request - support container linking

[hagmonk]

I know there are moves afoot in the docker community to do more sophisticated service discovery, but while that is getting sorted out, basic container linking support would be great.

Additionally, intelligent container restarting based on linked relationships could also be interesting. With my current setup, if I restart my database container I need to restart my whole stack to have it re-recognize the new database container.

[nickschuch]

Linking container support sounds really good. It's something I would like to see, maybe even hack on for a PR.

[dtornow]

+1 for linked containers

[tslater]

+1

[hhcordero]

+1

[brunowego]

+1

[mfkilgore]

+1

[jik1992]

+1

[greenkiwi]

+1

I am guessing I can always drop into bash, but having a mechanism to do this through the UI would be great.

[arcxyz]

+1

[azizur]

+1

[chermed]

+1

[greenkiwi]

This feature could be as simple as being able to just provide additional command line args.

On Jul 11, 2015, at 8:42 AM, Mohamed Cherkaoui [email protected] wrote:

+1

—
Reply to this email directly or view it on GitHub.

[andredasilvapinto]

+1

[vicary]

+1 service discovery is still not yet settled, we need something.

[davidangel]

+1

[nVitius]

There's a PR for this in #608, but it hasn't been updated in over a month.

[FrenchBen]

Just updated the PR to get it up to date. :)

[xlight]

where can I get this version?

[FrenchBen]

@xlight Need to get the PR updated and squashed. Hopefully the team can then take a look and see it merged

[bls20AWS]

+1

[klousiaj]

:+1:
Any status on this PR?

[FrenchBen]

@klousiaj Networking is the new Linking - It'd be a lot better and more functional to get it implemented.
A proposal was drafted: https://github.com/docker/kitematic/issues/1249
But no one chimed in :[

[sidharta]

+1

[jhgorse]

In lieu of complex solutions, perhaps a generic addition to the docker command line arguments for any unimplemented functionality in kitematic?

For instance, under Settings->Environment Variables there could be Settings->Other Arguments section for raw docker options typically passed on the command line. Such as --link, in this case.

Also, FWIW, I opened #1990 which is related to this need to link docker containers. Namely, I cannot seem to access the linux vm or native directory for the macOS Sierra docker-beta's dockerfile after setting it up with kitematic, so other ways of accessing the raw dockerfile seem appropriate.

Cheers,
Joe

[FrenchBen]

@jhgorse Linking of containers is a bit of an old way to do things - The proper way to do it these days seems to be via networking, where 2 network exist under the same network and thus can communicate. https://github.com/docker/kitematic/issues/1249
There's a feature request to get networking implemented into kitematic, but time has been the enemy so far.

[jhgorse]

Networking on os x is broken.
https://docs.docker.com/docker-for-mac/networking/#/known-limitations-use-cases-and-workarounds
https://github.com/docker/docker/issues/22753#issuecomment-243406719

I think the optimal solution may be to have a generic docker run argument extension as a catchall for unimplemented docker features in kitematic and general first step for testing a new ui wrapped around the existing functionality.

[FrenchBen]

@jhgorse it is not broken, it has limitations, which is that it cannot use the docker0 space, which is essentially host. This was used by most in the past to connect the different services, when a first class network would actually do the trick.
Connection of containers and host-exposed ports is a known issue. If you keep everything in containers, it works.

[jhgorse]

@FrenchBen that is an interesting definition of "not broken."

In any case, perhaps this ought to be renamed "docker for linux networking" then or rewritten to avoid the docker0 interface? https://docs.docker.com/engine/userguide/networking/

Also, FWIW, from the horse's mouth (above link):

If you want to communicate with container names in this default bridge network, you must connect the containers via the legacy docker run --link option.

[FrenchBen]

@jhgorse IMHO broken means it doesn't work at all - The fact that it works with limitations doesn't fit the definition of broken (it works under constraints).

@jhgorse I believe you missed the beginning of the sentence, which says that you communicate between containers via their IP (on the default bridge network) but if you need to communicate using the actual container names (once again using the default bridge network), then linking is used due to a lack of service discovery.

It then goes on to explain that you can create your own networks:
https://docs.docker.com/engine/userguide/networking/#/user-defined-networks
And explains that Each container in the network can immediately communicate with other containers in the network.

ps: the docs are not perfect, feel free to suggest an edit/change to them so that it better explains the above concept, as it can get very confusing.

[alexgalkin]

+1

[panga]

+1

[daaru00]

+1

[bwangfdu]

+1

[josedacosta]

+1
It's clearly missing!
A management of the "links", and a management of "composes"

Here is an example of the Synology Docker:

[daaru00]

I have create a PR about container links feature https://github.com/docker/kitematic/pull/2556

[regner]

The PR @daaru00 linked was merged and covers this issue. This issue can probably be closed.

[FrenchBen]

Thanks @Regner closing