Open thaJeztah opened 9 years ago
Note that the Network Changes in the API will affect https://github.com/jwilder/nginx-proxy, because the IP-Address is now returned per network
Thanks @thaJeztah
Looks like the upstream issue for fsouza/go-dockerclient
has been opened here: https://github.com/fsouza/go-dockerclient/issues/407
Correct, I noticed nginx-proxy stopped working for me for obvious reasons, so thought I'd open these issues in case they were overlooked; due to some issues, the API changes for networks didn't arrive until RC3
It doesn't look like the docs describe the changes to NetworkSettings
at all. Such as what the expected keys other than "bridge"
would be.
It seems like supporting the default case in things like nginx-proxy
would be pretty easy, but the details of supporting non-default networking cases seems like it could be tricky.
I think nginx proxy should use the default (bridge) networking for now, and add support for custom networks later.
not all docs wrt the new networking are merged yet; there's a big PR open with more details (not for API, but possibly more will be added)
Update on this issue; to make the transition to the new networks struct easier, we decided to keep the top-level Networksettings.IpAddress
(and related) around, at least for the 1.9 release; 1.9-RC4 brings back those properties. The values will be propagated with the default "bridge" network (if the container is attached to that)
@thaJeztah Just to clarify: if you say RC4 brings those properties back, does that mean that for 1.9 release both NetworkSettings.IPAddress
as well as NetworkSettings.Networks.bridge.IPAddress
are supposed to contain the (same) IP Address?
@compiaffe correct, see https://github.com/docker/docker/pull/17538
It seems that there's no ip on NetworkSettings.IPAddress
if the network name is not "bridge".
the I'm on docker 1.10.1, running an app with docker-compose (v2 style), and the ip address seems to be empty on docker-gen. This is what docker inspect --format='{{json .NetworkSettings}}' rob_hubot_1
looks like for this container:
{
"Bridge":"",
"SandboxID":"5a3cb1d0291d29d56df6c4496609cf42999115f3cff71cd571a38259fc7e2785",
"HairpinMode":false,
"LinkLocalIPv6Address":"",
"LinkLocalIPv6PrefixLen":0,
"Ports":{
"8080/tcp":null
},
"SandboxKey":"/var/run/docker/netns/5a3cb1d0291d",
"SecondaryIPAddresses":null,
"SecondaryIPv6Addresses":null,
"EndpointID":"",
"Gateway":"",
"GlobalIPv6Address":"",
"GlobalIPv6PrefixLen":0,
"IPAddress":"",
"IPPrefixLen":0,
"IPv6Gateway":"",
"MacAddress":"",
"Networks":{
"rob_default":{
"IPAMConfig":null,
"Links":null,
"Aliases":[
"hubot",
"803f511433"
],
"NetworkID":"3c5810876082d95a4352f8d320d56388baf9796ad8f3bdf56a52605790271767",
"EndpointID":"1ebc7c45df7d192ce71f7734a2320cd7a2e76f2e31c768aac9af8b95cb8433b7",
"Gateway":"172.19.0.1",
"IPAddress":"172.19.0.3",
"IPPrefixLen":16,
"IPv6Gateway":"",
"GlobalIPv6Address":"",
"GlobalIPv6PrefixLen":0,
"MacAddress":"02:42:ac:13:00:03"
}
}
}
It seems that there's no ip on
NetworkSettings.IPAddress
if the network name is not "bridge".
Correct; the NetworkSettings.IPAddress
is only there to provide backward compatibility with the old behavior (when only "bridge" networks were available). The Networks
struct is what replaces the old properties, so should be used going forward.
Docker 1.9-rc3 was just released for testing; https://github.com/docker/docker/pull/17000#issuecomment-150451872.
The Docker 1.9 release introduces a number of API changes (API version 1.21), among which are some breaking changes, for example;
/containers/(id)/stats
endpoint will now return statistics per interface (see https://github.com/docker/docker/pull/15786)NetworkSettings
struct now shows per-network information for a container (see https://github.com/docker/docker/pull/17422 and https://github.com/docker/docker/pull/17393)Additional changes can be found in the API changelog for v1.21, and pull requests that introduced API changes can be found on GitHub. (PR's that were not explicitly added to the milestone may not be included in that list)
Note that older versions of the API should still remain backward compatible
In case it's helpful, this is a diff for the Docker Remote API documentation (v1.21 vs v1.20);