Docker Networking

This lesson explains Docker networking fundamentals, default networks, how to create isolated user-defined networks, and how Docker resolves container names. It includes practical commands and examples you can run locally.

Default Docker networks

When Docker is installed, it creates three default networks: bridge, host, and none. Use docker run --network to choose a network at runtime or attach containers to networks you create.

Network	Description	Typical use
`bridge`	Default private bridge network (usually `docker0`) for containers without a specified network. Containers get internal IPs and can reach each other by IP.	Simple single-host container-to-container communication. Use `-p` to map container ports to host ports (e.g. `-p 8080:80`).
`host`	Shares the host network stack with the container (no network namespace isolation).	Low-latency networking when you need host-level networking. See warnings below.
`none`	Completely disables networking for the container (only loopback exists).	Highly isolated containers without network access.

Using --network host removes network namespace isolation. Ports opened by the container are exposed directly on the host, so you cannot run multiple containers that bind the same host port when using host networking.

Bridge network (default)

Docker creates a private bridge interface on the host (commonly docker0).
Containers attached to this bridge receive internal IP addresses (often in 172.17.0.0/16) and can reach each other by those IPs.
To reach containers externally, map container ports to host ports (for example: -p 8080:80).

Host network

--network host makes the container share the host’s network stack.
Container ports are accessible on the host without port mapping.
Port conflicts can occur because containers use the host port namespace.

None network

none gives a container no network interfaces except loopback and prevents external connectivity.

Isolating containers with user-defined networks

If you want to isolate sets of containers on the same host (so they cannot reach each other by default), create user-defined bridge networks with custom subnets. Containers on the same user-defined network can communicate using container names, and Docker provides an embedded DNS server for that network.

A diagram titled "User-defined Networks" showing a Docker host with two separate bridge networks (172.17.0.x on the left and 182.18.0.x on the right) each represented by a docker0 interface. Each network connects two "Web" containers with specific container IPs (e.g., 172.17.0.2/.4 and 182.18.0.3/.2).

Create a user-defined bridge network with a specific subnet:

docker network create \
  --driver bridge \
  --subnet 182.18.0.0/16 \
  custom-isolated-network
# returns network id, e.g. dba0fb9370fe

List all Docker networks:

docker network ls

Attach containers to the network when starting them:

docker run -d --name=mysql --network=custom-isolated-network mysql
docker run -d --name=web --network=custom-isolated-network my-webapp

You can also connect an existing container to a network:

docker network connect custom-isolated-network existing-container

Inspecting container network settings

To view a container’s IP address, gateway, and other network settings, use docker inspect:

docker inspect blissful_hopper

Example excerpt (JSON):

[
  {
    "NetworkSettings": {
      "Bridge": "",
      "Gateway": "172.17.0.1",
      "IPAddress": "172.17.0.6",
      "MacAddress": "02:42:ac:11:00:06",
      "Networks": {
        "bridge": {
          "IPAddress": "172.17.0.6",
          "MacAddress": "02:42:ac:11:00:06"
        }
      }
    }
  }
]

Name resolution: container names vs IPs

Using IP addresses to connect to containers is brittle because IPs may change (for example, after a restart). Prefer resolving containers by name where possible.

On the default bridge network, there is no embedded DNS for container names — containers can reach each other only by IP.
On user-defined networks (including networks created by Docker Compose), Docker provides an embedded DNS server at 127.0.0.11. This DNS resolves container names to their IP addresses for containers on that network.

Example: a Python MySQL client connecting by container name:

mysql.connect(host="mysql", user="user", password="pass", database="db")

Quick recipe:

Create a user-defined network.
Run both database and web app attached to that network.
Use the database container name (e.g. mysql) as the hostname in your app config.

Docker Compose automatically creates a user-defined network for each project. That is why service names in a Compose file act as DNS names for inter-service communication:

docker-compose up -d
# Compose creates a network like project_default and services can reach each other via service name

You can also manually recreate this behavior:

docker network create --driver bridge my-app
docker run -d --name=mysql --network=my-app mysql
docker run -d --name=web --network=my-app my-webapp

Under the hood

Docker networking is built on Linux kernel mechanisms:

Network namespaces: each container typically has its own network namespace to isolate network resources.
Virtual Ethernet (veth) pairs: veth pairs connect a container’s network namespace to the host bridge or to another namespace.

These are advanced topics worth exploring when you need a deeper understanding of how Docker networking works.

The image shows a slide titled "Under the Hood" with two colored cards: "Network Namespaces" (separate namespaces for each container) and "Virtual Ethernet Pairs" (connect containers together).

Summary & next steps

Use user-defined bridge networks to enable service name resolution and isolate groups of containers.
Avoid relying on container IPs; prefer container names on user-defined networks.
Use docker network inspect, docker inspect, and docker network ls to debug networking issues.

Try the practice exercises associated with this lesson.

Introduction

Docker Commands

Docker Images

Docker Compose

Docker Engine, Storage

Docker Registry

Docker on Mac & Windows

Container Orchestration - Docker Swarm & Kubernetes

Conclusion

Docker Run Commands

Docker Networking

Default Docker networks

Isolating containers with user-defined networks

Inspecting container network settings

Name resolution: container names vs IPs

Under the hood

Summary & next steps

Links and references

Watch Video

Practice Lab

​Default Docker networks

​Isolating containers with user-defined networks

​Inspecting container network settings

​Name resolution: container names vs IPs

​Under the hood

​Summary & next steps

​Links and references

Watch Video

Practice Lab

Default Docker networks

Isolating containers with user-defined networks

Inspecting container network settings

Name resolution: container names vs IPs

Under the hood

Summary & next steps

Links and references