Networking Between Containers¶

So far we have learned how to run containers, like our PostGIS database, which we have used for local development and testing. We have been connecting to this database using localhost and 5432, the published port of the container.

You are able to connect to your published containers through localhost:PORT because that process “originates” from the local machine itself. Technically the process originates from a container. But we publish, or bind, a host port to a container with docker run -p <host>:<container>. From that point onward any connections made on the [local] host machine’s port will be forwarded to the published container.

So how do we connect two or more containers? Generally speaking this is a question about networking between machines [containers] on a network. There are three options to consider for networking within the same Docker host:

• The simplest, but least reliable, solution is to use the default container network
• A less scalable, but more reliable, solution is to use a custom bridge network
• A (relatively) more complex, but more scalable and reliable, solution is to use docker-compose

Using the Default Network¶

By default all containers are connected to the bridge network when they are created. This network (along with the host and none networks) are all created automatically when the Docker daemon starts up. Within the bridge network every container is assigned a private (internal) IP address. These addresses are assigned within the bridge network’s subnet[work] range.

Containers can connect to each other using these private IP addresses. In the same way that any two machines on a network can connect to each other by their IP addresses. However, addresses on a network are rarely static.

Typically addresses are dynamically assigned as machines are added and removed from it. Containers behave the same as they are created and destroyed or assigned and unassigned from the default bridge network.

You can list all of the networks (default and custom) using the following command:

$ docker network ls

You can also inspect the details of a network using Docker. This will show you information about the network including with the containers that are assigned to it. You can see the network’s subnet range under IPAM.Config.Subnet. Under Containers you can see all of the containers connected to the network and their IP addresses (notice how they are all within the subnet range):

# inspect a network
$ docker network inspect <network name>

# inspect the default bridge network
$ docker network inspect bridge

# use sed to only show the container information (between Containers and Options sections)
$ docker network inspect bridge | sed -n '/Containers/,/Options/p'

To connect one container to another you just use their IP addresses along with the port the container’s process is running on.

By far using the default network addresses is the simplest mechanism of networking between containers. It can work great in a pinch. But this simplicity comes at the cost of reliance on unchanging addresses - which is not a practical expectation. In the next approach we will learn how to use hostname aliases in a custom network to resolve this dependency on a fixed IP address.

Using a Custom Network¶

In the previous section we learned about using hard-coded container IP addresses on the default bridge network. We also learned how using the IP addresses can lead to inconsistent behavior due to the ephemeral nature of containers and, by extension, their assigned addresses within a network.

Fortunately Docker lets us create custom user-defined networks that support networking between containers using aliases, or hostnames, instead of their mutable IP addresses. In these custom networks the aliases remain constant and are resolved into the IP address the containers are assigned. The hostname resolutions in each network are handled by an internal DNS that Docker manages.

Instead of hard-coding an IP address we can refer to a container by its alias and its internal IP will be resolved to the correct address. Even if that address changes in the future. This is true as long as the container is on the same network and given the same alias.

For our purposes we are only concerned with networking between containers on the same Docker host. This simplifies things for us. We can use a custom bridge network which happens to be the default driver used when issuing the network create command:

# create a bridge network by the given name
$ docker network create <network name>

# view all networks (3 defaults and the custom one created above)
$ docker network ls

# connect a container whose hostname will be the container name
$ docker network connect <network name> <container name>

# connect a container with a custom alias
$ docker network connect --alias <custom alias> <network name> <container name>

# disconnect a container
$ docker network disconnect <network name> <container name>

# connect to a custom network (instead of the default bridge) when running a container
$ docker run --network <network name> ...

# connect to a custom network AND give the container alias(es) on that network
$ docker run --network <network name> --network-alias <alias name>[,<other alias name>,...] ...

# create the network
$ docker network create my-network

# create the containers and connect them to the network
$ docker run --name service-one --network my-network ...
$ docker run --name service-two --network my-network ...

# note the container must have curl installed for this to work!

# the curl -v option prints out connection details
$ docker exec <container name> curl <other container alias>:<port> -v

# you will get an output like this
* TCP_NODELAY set
* Connected to <container alias> (172.X.X.X) port <port> (#0)
> GET / HTTP/1.1
> Host: <alias>:<port>

$ docker network create networking-test

# create a temporary directory to mount in the container
$ mkdir /tmp/networking-test

# create the file
$ echo 'using container aliases works!' > /tmp/networking-test/message

# the :ro volume option means "read-only"
$ docker run -d --rm --name server --network networking-test -v /tmp/networking-test/:/var/www/:ro launchcodedevops/simple-http

$ docker run -itd --name client --network networking-test launchcodedevops/simple-client

$ docker network inspect networking-test

# or print just the Containers section using sed
$ docker network inspect networking-test | sed -n '/Containers/,/Options/p'

# the -v, verbose, option will show connection data
$ docker exec client curl -v server:8080/message

# output
# we can see how the alias was resolved into the container IP on the network
...
* Connected to server (172.28.0.2) port 8080 (#0)
> GET /message HTTP/1.1
> Host: server:8080
...
<
using container aliases works!

# once the containers are stopped they will remove themselves automatically
$ docker stop server client

# remove the network
$ docker network remove

# remove the temp directory and file
$ rm -rf /tmp/networking-test