CODEWITHSUNDEEP
docker
tuxx
tuxx

Reputation: 503

Network communication between Docker images

I have 2 applications:

Each application is containerized in a Docker image. In the server Dockerfile I use:

...
EXPOSE 5150
...

I'm having trouble connecting to the server from the client:

$ docker run --rm -it --name server my-registry.com/server:0.0.1
$ docker run --rm -it --name client --link server:chat my-registry.com/client:0.0.1

I get connection refused.

Also telnet:

$ docker run --rm -it --name client --link server:chat --entrypoint=/bin/bash my-registry.com/client:0.0.1
root@f384b008ce68:/# env | grep CHAT_PORT
CHAT_PORT_5150_TCP_ADDR=172.17.0.54
CHAT_PORT_5150_TCP_PROTO=tcp
CHAT_PORT_5150_TCP=tcp://172.17.0.54:5150
CHAT_PORT_5150_TCP_PORT=5150
CHAT_PORT=tcp://172.17.0.54:5150
root@f384b008ce68:/# telnet $CHAT_PORT_5150_TCP_ADDR $CHAT_PORT_5150_TCP_PORT
Trying 172.17.0.54...
telnet: Unable to connect to remote host: Connection refused

Any ideas what I'm doing wrong?

Upvotes: 2

Views: 994

Answers (1)

larsks
larsks

Reputation: 311377

Each docker container runs in a separate "network namespace". The means that (a) each container has its own ip address and (b) localhost means "this container", and doesn't have anything to do with localhost in an other container.

If you want your services to be accessible from another container, you will need to configure them to not bind to localhost, and then access them using:

  • the container ip, or
  • the container name, when using --link, or
  • some sort of service discovery mechanism, or
  • publishing the ports on your host and accessing them via your host ip

Note that the EXPOSE directory is basically a no-op; containers running on the same host have, by default, unrestricted access to each other. Using EXPOSE does aid in service discovery when you use --link because it will result in populating environment variables in the linked container with information about the available services.

For more information:

Upvotes: 3

Related Questions