Skip to content

Docker - Networking

Docker provides powerful networking capabilities, allowing containers to communicate with each other, the Docker host, and external networks. Understanding Docker networking is crucial for building multi-container applications.

When Docker is installed, it creates several default networks. The most common one is the bridge network.

  • bridge: The default network containers connect to if no other network is specified. Containers on the default bridge network can communicate with each other using their IP addresses, but cannot resolve each other by container name.
  • host: Containers share the host’s networking stack. No network isolation.
  • none: Containers have no network interface, only a loopback device. Completely isolated network-wise.

You can see the default bridge network interface (often named docker0) on the Docker host using commands like ip addr show or ifconfig on Linux.

Docker provides commands to manage networks:

This command lists all networks available on the Docker host.

docker network ls

Output typically shows the default networks (bridge, host, none) and any user-created networks.

NETWORK ID NAME DRIVER SCOPE
ca411b7d6ebf bridge bridge local
2f89b2b5b01a host host local
3d1d7a7d5c5b none null local

Inspecting a Network (docker network inspect)

Section titled “Inspecting a Network (docker network inspect)”

Provides detailed information about a specific network, including its configuration, subnet, gateway, and connected containers.

docker network inspect bridge

The output is in JSON format. If you run a container and inspect the bridge network again, you’ll see the container listed under the Containers key, along with its assigned IP address.

# Start a container (it attaches to 'bridge' by default)
docker run -dit --name my-temp-container busybox
# Inspect the bridge network again
docker network inspect bridge

Look for the Containers section in the JSON output.

While the default bridge network is useful, user-defined bridge networks are generally recommended for applications involving multiple containers that need to communicate.

  • Automatic DNS Resolution: Containers on the same user-defined network can resolve each other by their container names. This eliminates the need to manage IP addresses or use legacy --link options.
  • Better Isolation: Provides network segmentation. Containers not connected to a specific user-defined network cannot access containers within it (unless ports are published).
  • Dynamic Connectivity: Containers can be attached to and detached from user-defined networks on the fly.

Creating a User-Defined Bridge Network (docker network create)

Section titled “Creating a User-Defined Bridge Network (docker network create)”
# Create a new bridge network named 'my-app-net'
docker network create my-app-net

By default, this creates a network using the bridge driver. You can specify other drivers (overlay for Swarm, custom plugins) using the --driver option.

Connecting Containers to a User-Defined Network

Section titled “Connecting Containers to a User-Defined Network”

Use the --network flag when running a container:

# Start a backend container on the custom network
docker run -d --name backend-db --network my-app-net redis:alpine
# Start a frontend container on the same network
# This container can now reach 'backend-db' using its name
docker run -d --name frontend-app --network my-app-net -p 8080:80 some-frontend-image

Inside the frontend-app container, you could now typically connect to Redis using the hostname backend-db.

You can inspect your custom network (docker network inspect my-app-net) to see the connected containers.