Connecting Docker Containers, Part One

Docker containers are self-contained, isolated environments. However, they’re often only useful if they can talk to each other.

There are many ways to connect containers. And we won’t attempt to cover them all. But in this miniseries, we will look at some common ways.

This topic seems elementary, but grasping these techniques and the underlying design concepts is important for working with Docker.

Understanding this topic will:

  • Help developers and ops people explore the broad spectrum of container deployment choices
  • Let developers and ops people to embark more confidently with a microservice design architecture
  • Empower developers and ops people to better orchestrate more complex distributed applications

Fortunately, the large number of connection options for containers enables a broad range of approaches, giving us the flexibility to choose an architecture that suits the needs of any application.

In this post, we’ll look at three of the older, more basic ways of connecting Docker containers. Using this knowledge and experience as a foundation, we’ll then move on to two newer, easier, more powerful ways in the next post.


Before we can demonstrate how containers can be connected, we need to create a pair of them for use in our examples.

The first image will be derived from a simple Ubuntu installation. It will act as a client container.

First, we create the container and attach to it:

$ sudo docker run -itd --name=client_setup ubuntu /bin/bash
$ sudo docker attach client_setup

Then, once we have a shell inside the container, we run:

$ apt-get install curl

If you do not see the shell, click the up arrow.

Now, detach from the client container using CTRL+p then CTRL+q.

Then, stop it, and commit:

$ sudo docker stop client_setup
$ sudo docker commit client_setup client_img

We now have an image called client_img to use.

The second container we want to use is, again, derived from an Ubuntu installation. But this time, we’ll modify it to run a Apache HTTP server.

First, we create it and attach, like before:

$ sudo docker run -itd --name=server_setup ubuntu /bin/bash
$ sudo docker attach server_setup

Then, once we have a shell inside the container, we install the Apache HTTP server:

$ apt-get install apache2

When the installation is complete, detach from the container using CTRL+p and CTRL+q.

Now, stop the container, and commit it:

$ sudo docker stop server_setup
$ sudo docker commit server_setup server_img

We now have two images: client_img and server_img.

Now we have this set up, we can explore the various connection possibilities.

The Docker Bridge

By default, a Docker container is isolated from other containers and the external network. Docker provides a bridge, the docker0 interface, which is created with the installation of the Docker Engine.

It is through the Docker bridge that communication is possible amongst containers and between containers and the host machine.

You can see the Docker bridge by running this command on a Docker host:

$ ifconfig docker0

You should see something like this in the output:

docker0   Link encap:Ethernet  HWaddr 02:42:a2:dc:0f:a8  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::42:a2ff:fedc:fa8/64 Scope:Link
          RX packets:1477 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2436 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:83901 (83.9 KB)  TX bytes:3606039 (3.6 MB)  

The bridge interface works locally, on a single Docker host, and is the connection mechanism behind all three approaches we cover in this post. In the next post, we’ll move on to the overlay interface, which allows us to network containers across multiple Docker hosts.

Exposing Ports

First, let’s see how we can run a server container so that it exposes port 80 (HTTP) to other containers.

To do so, I run the container with the expose command, which tells Docker to expose port number specified when it runs the container. An exposed port is one that other containers can reach.

Let’s run server_img as a container called server1, exposing port 80:

$ sudo docker run -itd --expose=80 --name=server1 server_img /bin/bash

We’ll name our containers sequentially (server1, server2, and so on) as we go.

Then, attach to the container:

$ sudo docker attach server1

Again, If you do not see the shell, click the up arrow.

Start the Apache HTTP server:

$ /etc/init.d/apache2 start

And get the IP address:

$ ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:ac:11:00:03  
          inet addr:  Bcast:  Mask:

Okay, so we have an IP address of Let’s test we can see that from a client container.

Open a second terminal.

Start the client1 container:

$ sudo docker run -itd --name=client1 client_img /bin/bash

Attach to it:

$ sudo docker attach client1

If you do not see the shell, click the up arrow.

Make a test connection to the server1 container’s IP address:

$ curl 

If everything works, you should see the HTML of the Apache HTTP server’s default page. This indicates the the client1 container is able to make connections to the server1 container’s HTTP port.

Port Binding

What if we want to expose our HTTP server to the host network, including application on the host machine, and other machines on the host network? In this scenario, we need to bind a host port to a container port.

To expose the Apache HTTP server to the host network, we need to bind port 80 on the server container to port 8080 on the host machine.

We can do this like so:

$ sudo docker run -itd -p 8080:80 --name=server2 server_img /bin/bash

The -p 8080:80 option is the thing to pay attention to here.

Now, attach to the container:

$ sudo docker attach server2 

If you do not see the shell, click the up arrow. And start the Apache HTTP server:

$ /etc/init.d/apache2 start

Now, from the host system, visit http://localhost:8080/ and you should see the Apache HTTP server default page.

apache default page

Any machine on your host network that can access port 8080 of your host machine will also be able to access this.

Linking Containers

Another approach to connecting containers involves something Docker calls linking.

When you link one container to another, Docker will make some information about the linked container available via environment variables.

Let’s take a look.

First, start the server container:

$ sudo docker run -itd --name=server3 server_img /bin/bash

Now, start the client container and link it to the server container, like so:

$ sudo docker run -itd --link server3 --name=client3 client_img /bin/bash

Notice the --link server3 option being used here.

Now attach to the client container:

$ sudo docker attach client3

And check out the available environment variables:

$ env | grep SERVER3

Docker also updates the /etc/hosts file in the client container to add server3 as a local hostname pointing to the server container.

To demonstrate this, run:

$ curl server3

You should see the same default HTML again.


In part one of this miniseries, we introduced the Docker bridge interface, which lets us connect containers on the same host.

We looked at three connection methods:

  • Connection through port exposure
  • Binding of the host port to the container port
  • Linking two containers through the link option

In part two, we’ll look at isolating containers inside user-defined networks. We’all also introduce the overlay interface, and take a look at how to use it for networking Docker containers across multiple Docker hosts. Even across datacenters and cloud providers!

About the Author

Dr Mazembo Mavungu Eddy is a Tech and Social Science Writer, Developer, Senior Research Consultant and Founder of Dielais. He lives in France and provides training and consultancy on Docker and related container technologies. Get in touch by writing to mazemb_eddy at or dielainfos at Follow me on Twitter: @mazembo

Leave a Reply

Your email address will not be published. Required fields are marked *