Introspection of external port

[terinjokes]

For some services, it would be nice to be able to introspect the external port associated with an internal port.

[crosbymichael]

@terinjokes docker ps displays both internal and external port information. Does that work for you?

[terinjokes]

@crosbymichael: No, though the initial bug report isn't helpful.

To clarify, it would be helpful if inside the docker instance, there was an official means to query about itself, including the external port being mapped to a local port.

[shykes]

I agree this is needed.

In 0.7 I would like to find a solution to a bunch of networking problems and requests. This is one of them.

[terinjokes]

@shykes Do you have an idea of how this might work from the perspective of a image maintainer? I'm starting to work on improvements to the Dockerfile this affects, and would be open to providing feedback.

[terinjokes]

Looks like part of this came in 0.6.5's links feature, I'm looking into that now.

[GaretJax]

As far as I can tell, the links feature does not solve this exact problem, but it could be solved in a similar way by just adding an environment variable to the container. Something along the lines of SELF_xxx_TCP_PORT=yyy (or_UDP_).

[mbrevoort]

+1 for exporting host mapped ports via environment variables like the links feature. It should also export the host IP as well. In other words, the container should be able to introspect how it is externally reachable.

[terinjokes]

+1 to @mbrevoort for explaining what I'm wanting in a much more straightforward fashion.

[crosbymichael]

@mbrevoort What do we do when the container is not publishing a port to the docker host or publishes to localhost of the docker host machine?

[mbrevoort]

@crosbymichael I think the container should only be presented with the environment variables when the -p option is specified for port(s) that the containers EXPOSE.

The ip seems like a sticky area.

One option would be to populate an environment variable with the ip if it was specified with the -p option as well (e.g. ip::containerPort as in 10.10.10.2::8080) so you might get something like this:

SELF_8080_TCP_PORT=49153
SELF_8080_IP=10.10.10.2

However, if you use 0.0.0.0 that isn't helpful (e.g. 0.0.0.0:8080:8080).

Maybe the host isn't included in this; maybe the host would have to be passed in with -e as you would today. The port would still be super helpful though in cases where you are relying on Docker to bind to a random free port.

[danbeaulieu]

+1. In our situation we have a lot of containers coming and going and rely on dynamic port allocation. The applications inside the containers need to know how to tell the outside world how to route to themselves, knowing the host ip and external port are required.

[jhliptak]

+1 Adding the ability to link to yourself would allow me to not run privileged containers (to use the API socket).

[matleh]

+1 that feature would allow a container to announce itself for service discovery (using etcd for example). Currently that has to happen outside of the container (with a "sidekick" in CoreOS).

[tamsky]

It certainly would be nice if docker -d was a responsible member of society... and on every container create event, it would also place the output from docker inspect into the new container's root at some well known location, perhaps: /docker-metadata.

A simple but inefficient substitute for the above fits in a tweet or the more verbose:

# Requires docker v.1.8.0 or later
while true ; do
    for container in $(docker ps -q) ; do
        docker inspect ${container} 2>&1 >/tmp/${container}.meta &&
        docker cp /tmp/${container}.meta ${container}:/docker-metadata &&
        rm /tmp/${container}.meta
        sleep 5
    done
done

The above shell snippet probably constitutes a working fix for: #3778 #8427 #1270.

[thaJeztah]

Looks like this is a duplicate of #1270, which is opened after this issue, but has more activity, so for housekeeping I'll close this one