2

I can link docker containers with the --link name:alias parameter, which will create several environment variables within the container, for example ALIAS_PORT_1234_TCP_ADDR, ALIAS_PORT_1234_TCP_PORT, ALIAS_PORT_1234_TCP_PROTO.

The ALIAS_PORT_1234_TCP_ADDR var can be used to detect the IP of the linked container (even though is is advisable to use the etc/hosts entry instead, because it will be updated on container restart, while the env vars do not change).

But it is not obvious to my, what I could use these other two variables for. In the given example ALIAS_PORT_1234_TCP_ADDR will be 1234 and ALIAS_PORT_1234_TCP_PROTO will be tcp - but both values are already in the name of the vars.

Could somebody enlighten me, about the intended meaning and use of these variables?

Are there scenarios, in which the exposed port of a linked container is different to what it declares with EXPOSE? I know that I can bind a container port to the host via -p but my understanding was, that this has no consequence for linked containers, because they will talk directly to the port of the linked container and need not talk to the host (which would be more difficult because it is not so easy to get the IP of the host inside a container).

Also, why would the protocol of a port change or need to be detected?

matlehmann
  • 392
  • 3
  • 8

2 Answers2

0

Are there scenarios, in which the exposed port of a linked container is different to what it declares with EXPORT

If you mean EXPOSE, then the main difference is that without link, you would need to publish the port to the host, in order for other container to discover it and communicate back to the first container which exported its port.

But with --links, you don't have to use -P or -p <hostport>:<containerport>, you can discover the port exposed by the first container with the environment variables. The host wouldn't need to use one of its port to channel back to the first container port.

See "Communication between linked docker containers" as an example which would use all three environment variables.

If you want to invoke invokes the URL udp://Container_1_IP:5043 from Container_2, you need the --link to set all 3 variables in order to use the right IP, port and protocol.

The OP comments:

Sure, I can construct "udp://Container_1_IP:5043" from env vars - but I can not see, why I would need to do: 

$ALIAS_PORT_5043_UDP_PROTO:// $ALIAS_PORT_5043_UDP_ADDR:$ALIAS_PORT_5043_UDP_POR‌​T

That is true, but doesn't take into account port range (with PORT_START and PORT_END environment variable)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Yes, this is in line with my understanding but does not shed more light onto the question, why I would need ALIAS_PORT_1234_TCP_PORT. – matlehmann Apr 10 '15 at 09:06
  • @matlehmann that is what my edited answer illustrates: you need all three to build the right url to use from container2 to container1 (unless you rely on their naming convention, but that isn't very safe) – VonC Apr 10 '15 at 09:07
  • @VonC If you know the name of the variable, you know its value, so what's the point? – Adrian Mouat Apr 10 '15 at 09:11
  • I read your linked question but could not find any use of the env vars. It talks about their existence, but does not say, how to use them. – matlehmann Apr 10 '15 at 09:12
  • @AdrianMouat the point is: if you need *just* the port or *just* the protocol, the you need to make some string manipulation splitting. As opposed to simply use the right environment variable. – VonC Apr 10 '15 at 09:13
  • @VonC That doesn't make sense. I have to know the constituent parts of the variable before I can address it by name. – Adrian Mouat Apr 10 '15 at 09:14
  • @matlehmann those environment are use in concatenation in order to build the used url. `udp://Container_1_IP:5043` is the result of `$ALIAS_PORT_1234_UDP_PROTO://$ALIAS_PORT_1234_UDP_ADDR:$ALIAS_PORT_1234_UDP_PORT` – VonC Apr 10 '15 at 09:15
  • @VonC No it's not - the port would be 1234 in that case. We must have known that to build the variable name, so why do we need the variable? – Adrian Mouat Apr 10 '15 at 09:19
  • 1
    This does not make sense to me. Sure, I can construct "udp://Container_1_IP:5043" from env vars - but I can not see, why I would need to do that. I think your example is wrong, it would be `$ALIAS_PORT_5043_UDP_PROTO://$ALIAS_PORT_5043_UDP_ADDR:$ALIAS_PORT_5043_UDP_PORT`. Aside from the address, this does not add any information: I know the protocol is "udp" and I know the port is "5043". So it is just a more complicated way to write `udp://$ALIAS_PORT_5043_UDP_ADDR:5043` (which should even be written as `udp://alias:5043` using the `/etc/hosts` entry). – matlehmann Apr 10 '15 at 09:33
  • @matlehmann I agree. Maybe a legitimate case would be port range? See my edited answer. – VonC Apr 10 '15 at 09:43
0

I have wondered this for a long-time myself. I think the environment variables are mainly just a form of documentation; you can call env to discover what ports the container exposes. I suppose one use case may be to parse the names of the variables from an environment in a linked container; this would allow you to choose at run-time which port or ports to use. (Even then it would seem to make more sense to have a variable such as ALIAS_PORTS rather than names with the values already encoded).

Also, I think this may be changing in the future as the networking features of Docker evolve.

Adrian Mouat
  • 44,585
  • 16
  • 110
  • 102