Expose weave network to docker inspect

[hesco]

I believe that the zettio-weave project needs to sort out how to use its run, attach and detach subcommands to inject and maintain information about the weave bridge into the docker inspect output.

https://github.com/hesco/hesco-weave#to-do-tasks-for-other-projects

[rade]

Why? (I can think of some reasons, but would rather hear them from you)

run is doable since we can stuff information into the container process env with docker run --env=...; docker inspect reports on the environment.

I don't think attach and detach can inject information without an extension to docker.

[hesco]

docker inspect is easily scriptable and ought to be the goto source of truth about a container.

Using it is slightly easier than shell'ing out to the container and running ifconfig or ip.

Many folks do not install an sshd daemon on their containers and so must attach or use nsenter to introspect their boxes instead.

It would be convenient.

This data structure:

    "NetworkSettings": {
        "Bridge": "docker0",
        "Gateway": "172.17.42.1",
        "IPAddress": "172.17.0.33",
        "IPPrefixLen": 16,
        "PortMapping": null,
        "Ports": {}
    },

ought to be an array of interfaces, rather than simply reporting on the docker bridge.

And doing so would support things I'd like to do to expose network data about containers as facter facts on both the container and on the docker host.

Just off the top of my head.

-- Hugh

[errordeveloper]

Docker lacks support for this at the moment, as far as I can tell... However, I had been looking at how to make Docker use Weave's bridge, that way Docker allocates IPs and will thereby tell IP of the container which is on the Weave network. the only issue with this approach is that it ends up using subnet-per-host model, rather then per application...

[rade]

the only issue with this approach is that it ends up using subnet-per-host model, rather then per application...

That's a big deal.

[errordeveloper]

FYI, there appear to be forks of libcontainer that implement support for multiple network interfaces... e.g. ajwdev/libcontainer@d486ac7 and MalteJ/libcontainer@7742859, but I'm not sure whether this will make it upstream anytime soon.

[rade]

Docker lacks support for this at the moment, as far as I can tell

moby/moby#9013 is designed to fix that.

[rade]

Container labels, introduced in docker 1.6, allow us to add weave IPs to container meta data. But only on container creation, since, unlike moby/moby#9013, they can only be set then and are immutable.

A weave docker network plugins might also give us this functionality, depending on what, if anything, gets placed into the container metadata (or other data retrievable via the docker remote api) by the network plugin mechanism.

[bboreham]

A user (via IRC) tells us they do the 'docker-uses-weave-bridge' thing to get the weave IP to show up in docker inspect.
Unfortunately that takes the user into territory we don't test for...

[rade]

A user (via IRC) tells us they do the 'docker-uses-weave-bridge' thing to get the weave IP to show up in docker inspect.

Did they say why they are doing that? In particular, why would weave ps not work for them?

[bboreham]

They mentioned "configurator+consul" using the docker inspect API.

[rade]

They mentioned "configurator+consul" using the docker inspect API.

Hmm. Can't see it in the code, though I didn't look very hard.

If true I suspect these would work only if the weave IP replaced the docker IP in the result of docker inspect. @progrium is that true?

[enxebre]

Hi there, Similar probem here. I am using registrator for storing the container (weave) ips into consul. When using the weave bridge as the default docker bridge it just work as expected but as per https://github.com/gliderlabs/registrator/blob/583c5bd34a15c2c90448b26a3cf17188691c0cbc/bridge/util.go#L72 it won't work when weave generating ethw as "container.NetworkSettings.IPAddress" still will be the docker0 bridge ip.

So ideally?:

• docker rest api would return a list of all interfaces in NetworkSettings for the endpoint /containers/(id)/json
• Docker client would be aware of this https://github.com/fsouza/go-dockerclient/blob/725c89a4f66779033847b35f424d59ba44a7ded1/container.go#L130
• And registrator would allow a --interface flag https://github.com/gliderlabs/registrator/blob/583c5bd34a15c2c90448b26a3cf17188691c0cbc/bridge/util.go#L72

I am guessing this woudln't be a problem if libnetwork plugins become stable?
https://github.com/docker/docker/blob/3ee15acaadc3f25c90ea2c4de2e5ab1a12d8e042/experimental/plugins_network.md

https://github.com/weaveworks/docker-plugin