Bridge Networking in Docker: An Overview of Network Isolation in a Container Environment
In the world of Docker, deploying a container is not simple; properly configuring a container architecture requires strong networking capabilities. A web application with a cluster of databases, applications, and load balancers spanning numerous containers that need to communicate with one another would have a different network architecture than one designed to run on a single Docker container.
Networking allows containers to communicate with each other and with the host system. Containers run isolated from the host system and need a way to communicate with each other and with the host system.
Docker's Default Networks
Three network drivers/interfaces with different use cases are automatically created for you when you install Docker:
Bridge (docker0)
A container connects to this network when it starts running without specifying a network. Containers connected to the bridge network are given an internal IP address to communicate with each other.
Host
A container shares the networking namespace of the host when using the host network mode. As a result, the host's IP address and port will be used by the container to isolate and execute the process directly on the host.
None
As the name indicates, this mode disables the networking stack of the container. The host, other containers, and external systems are all inaccessible to containers running without network. It becomes useful when you do not require any network connectivity or complete isolation.
To view all networks, including the default ones, you can use the command:
docker network ls
The output is as:
Bridge Networking; An interactive demo
The default network mode in Docker. It creates a private network between the host and containers, allowing containers to communicate with each other and with the host system.
If you want to secure your containers and isolate them from the default bridge network, you can also create your own bridge network.
docker network create -d bridge <my_bridge_name>
Now, if you list the available networks, the new bridge is added.
docker network ls
NETWORK ID NAME DRIVER
xxxxxxxxxxxx bridge bridge
xxxxxxxxxxxx my_bridge_name bridge
xxxxxxxxxxxx none null
xxxxxxxxxxxx host host
Now, if you want to see containers' details in the bridge network, you can use the following command:
docker network inspect bridge
For a demo, we run two containers named viz. login and logout using command:
docker run -d --name login nginx:latest
docker run -d --name logout nginx:latest
Now, if we hop in to the running login container using command:
docker exec -it login /bin/bash
Currently the running containers are:
Now, if we run the command
docker inspect logout
We see that its IP address is 172.17.0.1
Now returning back to the interactive bash of login, if we ping the IP address of logut (172.17.0.1), we get:
This means that, both the login and logout are now connected via a bridge network.
Now, we create a new network named secure-network using the command:
docker network create secure-network
Now, in this network, we isolate a new container named finance.
We run a new named container named finance under this network using the command:
docker run -d --name finance --network=secure-network nginx:latest
Now, if we inspect the info of this container using command:
docker inspect finance
We see that the IP of this container is in new subnet, which in our case is 172.19.0.1
Moreover, the network is also secure-network (for previous one, it was bridge).
Now, if we ping this from the login interactive bash, we cannot get any info of this container. This implies that our container is isolated from the other two. This enhances the security too.
In this way, we created the three containers, among which two were in same subnet and one was isolated from the other two.