User defined bridge on Docker network

In this article, we are going to discuss why you should use a user-defined bridge network over default bridge networks. We will also demonstrate the same using practical examples.

If you use a user−defined bridge for Container networking, all the Containers in that network automatically exposes all the required ports to each other but not to the external world. This increases interoperability among the containers and provides better isolation.

When you create Docker Containers using the default bridge network, accessing each other can only be done using IP addresses. But in case of user-defined bridge networks, you can access them using names or aliases.

In order to connect or disconnect Docker Containers, you can do it easily and on the go when in user-defined networks. But in case of default bridge networks, you need to stop the container and reassign them with other network options. If a different group of applications in your user-defined bridge network has different requirements, you can configure them easily.

• Create a Bridge Network

Let’s create a bridge network called alpine-net using the following command.

sudo docker network create −−driver bridge my−alpine−net

This returns the network ID of the created network.

• List all the networks

To check whether the my−alpine−net bridge network has been created successfully or not, list all the networks.

sudo docker network ls

You will find that the my−alpine−net network has been created using the bridge driver and local scope.

• Inspect alpine−net

You can now inspect the my−alpine−net bridge network using the following command.

sudo docker network inspect my−alpine−net

You will find that the network currently does not contain any container associated with it.

• Create Containers

Let’s try to create Containers and associate them with different network specifications.

We will create 3 Alpine Image Containers here.

• Create a container called “my−alpine−01” which is to be connected to the default bridge network.

• Create another container called “my−alpine−02” which is to be connected to the my−alpine−net network.

• Lastly, create another container called “my−alpine−03” which is to be connected to both default bridge and the my−alpine−net networks.

sudo docker run −dit −−name my−alpine−01 alpine ash
sudo docker run −dit −−name my−alpine−02 −−network my−alpine−net alpine ash
sudo docker run −dit −−name alpine3 alpine ash
sudo docker network connect my−alpine−net alpine3

• Inspect the networks

After we have created the Docker Containers and associated them with the networks, we can now inspect the networks.

sudo docker network inspect my−alpine−net
sudo docker network inspect bridge

You will find that the my−alpine−01 and my−alpine−03 containers are associated with the default bridge network. Also, the my−alpine−02 and my−alpine−03 containers are associated with the my−alpine−net network.

• Observations

The containers my−alpine−02 and my−alpine−03 are connected in the my−alpine−net user defined bridge network. You can go to any one of these containers and ping the other using the name of the container or the aliases.

The containers my−alpine−01 and my−alpine−03 are connected to the default bridge network. If you go to any one of these containers and try to ping the other, you will need to specify the IP addresses and you cannot do it with the name or aliases of the containers.

sudo docker attach my−alpine−03
ping −c 3 172.17.0.2

The above commands will be successful. Here, we went into the my−alpine−03 container and pinged my−alpine−01 container using its IP address.

sudo docker attach my−alpine−02
ping −c 3 my−alpine−03

The above commands will also be successful because we are in a user−defined bridge network and pinged the other container using name. However, the below commands will throw an error.

sudo docker attach my−alpine−01
ping −c 3 my−alpine−03

Also, if you enter my−alpine−02 container and try to ping my−alpine−01 container, it would throw an error because they are on different subnets.

To conclude, in this article we saw the advantages of creating a user-defined customized bridge network over the default bridge networks. You can access other containers in the user−defined bridge network through their names or aliases and also it provides better interoperability when compared to the default one.