Docker's Default Bridge Network is a critical component for container communication, isolation, and external connectivity. As a developer, understanding this network and how it operates is fundamental for building and deploying containerized applications effectively.
What is the Docker Default Bridge Network?
When you install Docker, a default bridge network named « bridge » is automatically created. This network serves as the foundation for container networking and offers essential features for developers.
The default bridge network is designed to isolate containers from the host machine’s network. This isolation ensures that containers do not interfere with each other or with the host system, providing a secure and controlled environment.
Example 1: Creating Containers on the Default Bridge Network
You can create containers attached to the default bridge network using the
docker run command. Here’s an example of launching two containers and inspecting their network settings:
# Create a container named "webapp1" running an NGINX web server docker run -d --name webapp1 nginx # Create another container named "webapp2" running an Apache web server docker run -d --name webapp2 httpd # Inspect the network settings for "webapp1" docker network inspect bridge
In this example, both containers are connected to the default bridge network. You can find their internal IP addresses, allowing them to communicate with each other over the network.
Private Internal IP Addresses
Containers attached to the bridge network can communicate with each other over private, internal IP addresses. Docker assigns each container a unique IP address within the subnet of the bridge network. This IP address allows containers to interact with each other using standard networking protocols.
Example 2: Container Communication Using Container Names
The default bridge network provides DNS resolution for containers based on their names. Let’s see how you can use this to enable one container to communicate with another:
# Create a container named "webapp3" running a simple web server docker run -d --name webapp3 -p 8080:80 nginx # Create a container named "client" to send requests to "webapp3" docker run -it --name client alpine sh # Inside the "client" container, use the container name to access "webapp3" wget http://webapp3 # You can also use the internal IP address wget http://172.17.0.2
In this example, the « client » container communicates with the « webapp3 » container by using its container name. This DNS resolution simplifies inter-container communication.
External Connectivity via NAT
Although containers on the default bridge network are isolated, they can access the external world through Network Address Translation (NAT). Docker sets up NAT rules, allowing containers to initiate outbound connections.
Example 3: External Connectivity via NAT
Containers on the default bridge network can access external resources. Here’s an example of how a container can access external websites:
# Create a container that accesses an external website docker run -it --name external-access alpine sh # Inside the "external-access" container, try accessing a website wget https://www.google.com
The « external-access » container can access external websites as Docker sets up NAT rules for outbound connections.
To allow external access to a container service, you can use port mapping.
Example 4: Port Mapping
Here’s an example of exposing a containerized web service to the host’s network:
# Create a container named "webapp4" running an NGINX web server and map port 8080 to 80 docker run -d --name webapp4 -p 8080:80 nginx
Now, you can access the NGINX web server from your host machine at « ` http://localhost:8080« `
In conclusion, the Docker Default Bridge Network is a foundational element for container networking. Developers can leverage it to build isolated, interconnected containerized applications and gain a deep understanding of networking concepts that are vital when working with Docker.