Intro

In this blog, I will be talking about one of the network drivers, that is the "bridge" driver. This blog will provide you an hands-on experience. It's going to be more practical and less theoretical.

So in this world of docker, you are going to be a magician, commands will be your spells, and docker client will be your magic wand. So, let's get started, shall we?

Create a user-defined custom bridge network

We'll create our own custom bridge network by following below steps:

1. Execute docker network create --driver <DRIVER> <networkName> command to create a custom network.
   • DRIVER options → bridge, ipvlan, macvlan, overlay, host, null. In this case, we'll use "bridge" as a driver.
2. Run docker network lsto list all networks.

3. Here, I am creating a network named setu of driver type bridge. I would like to draw your attention to another network named bridge.

   This is the default network of type "bridge". It's name is also bridge. When you start Docker, this default bridge network is automatically created. We'll learn more about it in the next section. The above screenshot was taken from Network Chuck's amazing video on Docker networking. Check it out if you haven't!

Inspecting a network

You can inspect a network by executing docker network inspect <networkName> or docker network inspect <networkID> command.

1. First of all, let's list all networks by running docker network ls command.

2. Let's inspect network named setu.

   Findings and Learning

   • Observe the Containers field. It's empty. This means that no container is connected to this setu network.
   • If you run a container without specifying any network, then this newly-started container will get connected to the default bridge network.
     • You can check this by running a container named test without specifying any network to connect to, and then inspecting the default bridge network. In the Containers column, you will see the presence of the test container. The above screenshot was again taken from Network Chuck's video [tutorial] (youtube.com/watch?v=bKFMS5C4CG0). Check it out!

Connect a container to a user-defined custom bridge network

There are two scenarios -

1. Connecting container to a network when you start the container: To do so, use the --network flag in the docker run command. You can only connect to one network during the docker run command, so if you wish to connect to other networks use the docker network connect command afterwards. For now, let's just forget about docker network connect and focus on the mission at hand. Eg,

   • Run docker run -itd --network setu --name test ubuntu command to run a new container named test and connect it to an existing bridge network named setu.
   • On inspecting the setu network you can verify that the test container has been added to the Containers list.

2. Connecting an already running container to a network: I have discussed it in detail in the next to next section named "Connecting a running container to a network".

Disconnecting a container from a network

Just run the docker network disconnect <networkName> <containerName> command.

Workshop #1

Aim: Disconnect test container from the bridge network.

Steps:

1. As you can see below that the test container is connected to the bridge network.
2. Run docker network disconnect bridge test command to disconnect test container from the network named bridge.
3. If you inspect the bridge network, then you can see that the test container has been removed from the Containers list.
   

Connecting a running container to a network

Just run the docker network connect <networkName> <containerName> command to connect already running containerName to the networkName network. You can connect a container to multiple networks.

Workshop #2

Aim: Connect already running test container to the bridge network.

Steps:

1. As you can see below that no container is attached to the bridge network.
2. Run docker network connect bridge test to connect test container to the network named bridge.
3. If you inspect the bridge network then you can see that the test container has been added to the Containers list.
   

Communication between containers on the same bridge network

There's something that I want you to know before we check whether communications happens between containers on the same bridge network or not.

• In the Docker Documentation it is stated that,

  In terms of Docker, a bridge network uses a software bridge which allows containers connected to the same bridge network to communicate, while providing isolation from containers which are not connected to that bridge network.

  The Docker bridge driver automatically installs rules in the host machine so that containers on different bridge networks cannot communicate directly with each other.

• Make sure that the containers you are dealing with are in running mode. If they are stopped, then you can run them by executing docker start <containerName> command. So, let's get out hands dirty with this workshop!

Workshop #3

Aim: To check whether containers named ron and harry, that are on the same bridge network named Gryffindor, can directly communicate or not.

Steps:

1. First create a network named Gryffindor.

2. Add containers named harry and ron to this network i.e. Gryffindor.

3. Inspect the Gryffindor network to verify that both harry and ron are added to this network.

4. Now, enter into one of the containers. I'll enter into the harry container. Once you are in the container, then run apt update $$ apt upgrade -y && apt install iputils-ping command.

   Wait! Don't panic! Let me explain what this command does. It just updates the system, and upgrades the installed packages. And, what apt install iputils-ping does is that it installs ping utility. We'll use this ping command to check whether we can communicate with the container ron or not.

5. As Gryffindor is a user-defined bridge network, therefore, we can ping the another container that is present in the same network(i.e Gryffindor) using the container name. If it was a default bridge network, then we can ping the other container using it's ip address only.

   So, ping the container ron by executing ping ron command in the harry container.

   As you can see, 8 packets transmitted, 8 received, and 0% packet lost. This means that both ron and harry can communicate over the same Gryffindor network.

Conclusion: Containers connected to the same network can communicate directly.

Communication between containers on different bridge network

Aim: To check whether containers named harry and draco that are on different bridge networks named Gryffindor and Slytherin respectively, can communicate or not.

Steps:

1. We have already created the bridge network named Gryffindor and connected container harry to it. Now, I'll create another bridge network named Slytherin and connect container named draco to it.

2. Find the ip address of the container draco by executing docker inspect draco | grep "IPAddress" command. This ip address is what we will use to ping when we will be in container harry. To ping, we can only use ip address of draco and not it's name because both harry and draco are connected to different networks.

3. Let's try to see whether container harry can communicate with container draco having ip address 172.21.0.2 or not. Remember that they both are connected to different networks. harry is connected to Gryffindor network, and draco belongs to Slytherin.

   Run ping 172.21.0.2 inside the harry container.

Conclusion: Containers connected to different networks can't communicate directly because there's a layer of isolation.

Overview

In this blog, we learnt that if a container is not connected to a specific network during run-time then it will get connected to default bridge network.

By creating a custom bridge network, unrelated containers (i.e. containers in different bridge networks) can't communicate with each other, thus resulting in better isolation of containers.

We also learnt that containers on the default bridge network can only access each other by IP addresses, while on a user-defined bridge network, containers can resolve each other by name or alias.