Docker networking allows containers to communicate with each other and the outside world. It is a crucial part of Docker, providing a way for applications within containers to send and receive data.
The Default Bridge Mode in Docker is a key networking mode that enables isolated communication between Docker containers and the host.
The Docker bridge driver (software device running within a host machine's kernel acting as a TCP/IP Link Layer device) automatically installs rules in the host machine so that containers on different bridge networks can't communicate directly with each other. This bridge driver acts as a virtual switch to which containers are connected.
Network Isolation
When running in bridge mode, each Docker container is connected to a private internal network hosted by the Docker daemon on the host machine. This network is isolated from the external network, providing a secure environment for container communication.
After Docker is installed, it creates a virtual network bridge, typically named docker0, on the host machine. This bridge acts as a virtual switch to which containers are connected.
Image credits: David Omokhodion
We can find the the interface of the default bridge network by using ifconfig or ip addr show commands:
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:90:68:1f:7f txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
To find the information about the default bridge network use docker network ls command:
NETWORK ID NAME DRIVER SCOPE
f4d2e21e057a bridge bridge local
NETWORK ID: f4d2e21e057a
This is a unique identifier for the network within the Docker system. Each Docker network is assigned an ID like this to differentiate it from others. It's used internally by Docker to manage networking functionalities.
NAME: bridge
This is the name of the network. In this case, bridge is the default network that Docker creates automatically. When you run a container and do not specify a network, Docker connects it to this bridge network by default.
DRIVER: bridge
The driver indicates the type of network. Here, the bridge driver is used, which is the standard network driver in Docker for creating a network on a single host.
The bridge driver creates a private network internal to the host so that containers on this network can communicate with each other. Containers on different bridge networks are isolated from each other.
SCOPE: local
This indicates the scope of the network's effect. local means that this network only facilitates communication on the local Docker host. Containers attached to this network will only be able to communicate with each other and the host on this single machine.
This is in contrast to networks with a global or swarm scope, which are used in more complex configurations like Docker Swarm, where containers might need to communicate across different hosts.
Internal IP Addressing
Each container connected to the bridge network is assigned its own internal IP address. Containers can communicate with each other using these IP addresses.
The default bridge network (docker0) typically uses the 172.17.0.0/16 subnet by default. This means the IP addresses assigned to containers connected to this default bridge network range from 172.17.0.1 to 172.17.255.254.
It's important to note that Docker selects the default subnet from private IP ranges defined by RFC 1918, and it might choose a different range if 172.17.0.0/16 is already in use. However, 172.17.0.0/16 is the most commonly seen default.
You can check the exact subnet and gateway used by your Docker installation with the following command:
docker network inspect bridge --format '{{json .IPAM.Config}}'
This command will give you detailed information about the IP address management (IPAM) configuration for the default bridge network, including the subnet and gateway.
[{"Subnet":"172.17.0.0/16","Gateway":"172.17.0.1"}]
Containers on the bridge network are isolated from the host's network, although the host can communicate with the containers.
Docker uses NAT(Network Address Translation) to manage the container's access to the external network. When a container needs to communicate with the outside world, Docker translates the container's internal IP address to the host's IP address.
Port Mapping and Exposing Ports
By default, containers on a bridge network cannot be accessed from outside the host machine. To enable external access, specific container ports must be exposed and mapped to the host's ports.
This is done using the -p or --publish flag in the docker run command. For example, mapping a container's port 80 to port 8080 on the host is done with -p 8080:80.
docker run -p 8080:80 <your-web-server-image>
DNS and Service Discovery
Containers on the default bridge network can only access each other by IP addresses, unless you use the --link option, which is considered legacy. On a user-defined bridge network, containers can resolve each other by name or alias.
Docker containers use the same DNS servers as the host by default, but you can override this with --dns. This flag specifies the IP address of a DNS server.
By default, containers inherit the DNS settings as defined in the /etc/resolv.conf configuration file. Containers that attach to the default bridge network receive a copy of this file. Containers that attach to a custom network use Docker's embedded DNS server. The embedded DNS server forwards external DNS lookups to the DNS servers configured on the host.
Security and Network Policies
The bridge network is protected by firewall rules that manage and restrict the flow of traffic to and from the containers. On Linux, Docker manipulates iptables rules to provide network isolation.
Users can implement additional network policies for enhanced security. For example, If you're running Docker on a host that is exposed to the Internet, you will probably want to have iptables policies in place that prevent unauthorized access to containers or other services running on your host.
You can add iptables policy before Docker's rules. In general, Docker installs two custom iptables chains named DOCKER-USER and DOCKER, and it ensures that incoming packets are always checked by these two chains first. These chains are part of the FORWARD chain.
All of Docker's iptables rules are added to the DOCKER chain. Do not manipulate this chain manually. If you need to add rules which load before Docker's rules, add them to the DOCKER-USER chain. These rules are applied before any rules Docker creates automatically.
To allow only a specific IP or network to access the containers, insert a negated rule at the top of the DOCKER-USER filter chain. For example, the following rule restricts external access from all IP addresses except 192.168.1.1:
iptables -I DOCKER-USER -i ext_if ! -s 192.168.1.1 -j DROP
Use Cases
Here are several common use cases for the default bridge network:
bridge network is not recommended for production.1. Development and Testing Environments
Isolated Environment: The default bridge network is ideal for development and testing, where you need an isolated network environment to run and interact with your containers without affecting your host network or being affected by it.
Multiple Containers: When you are running multiple containers that need to interact with each other (like a web application and a database), the default bridge network allows these containers to communicate seamlessly.
2. Simple Web Applications
Single-Host Web Services: For simple web applications running on a single host, the default bridge network is often sufficient. For example, you could run a web server in one container and a database in another, with both containers on the same bridge network.
Port Mapping: You can map the ports of these services to the Docker host's ports to make them accessible from outside the host.
3. Running Standalone Containers
- Single Container Applications: If you have standalone applications that don't need to communicate with other containers or require advanced networking features, the default bridge network provides a simple and quick solution.
4. Legacy Applications
- Migration to Containers: For legacy applications being migrated into containers, using the default bridge network can be a first step in the process, offering a straightforward method to containerize the application without immediately needing to address complex networking concerns.
5. Network Segmentation
- Isolation from Host Network: When you need to keep container traffic segmented from your host network for security or organizational reasons, the default bridge network offers this isolation by default.
6. Small Scale Deployments
- Resource Constraints: In environments with limited resources, such as small servers or personal computers, the default bridge network is a lightweight solution that doesn’t require additional overhead or complex configuration.
While the default bridge network in Docker is not as feature-rich or scalable as user-defined bridge networks or other advanced networking options like overlay networks, it provides a simple, out-of-the-box solution for a variety of basic use cases. It's particularly useful in scenarios where simple networking is sufficient or when starting out with Docker. However, for complex, multi-host, or production environments, more advanced networking options are recommended.
Workshop: Use the default bridge network
Go through the workshop exercise provided by Docker Docs to understand the key features of the default bridge network.
google.com), Docker translates the container's internal IP address to the host's IP address. It doesn't mean that the container has direct access to the host network. Containers on the default bridge network have their own private internal IP addresses and are isolated from the host’s network.