Introduction

Docker containers are designed to be portable and isolated, but they rarely run in isolation. Containers need to communicate with each other, with the host system, and with external services. Understanding Docker’s networking model is essential for building reliable, secure, and performant containerized applications.

Docker provides several built-in 네트워크 drivers — bridge, host, overlay, macvlan, ipvlan, and none — each suited to different use cases. This 가이드 covers each driver in depth, along with DNS 해상도, port mapping, security isolation, and Docker Compose networking patterns.

Understanding Docker 네트워크 Drivers

Every container has a virtual 네트워크 인터페이스 (veth pair) connected to the host. Docker uses 네트워크 namespaces to give each container an isolated 네트워크 stack with its own IP address, routing tables, and ports.

The docker network command is the control center for managing networks:

# List all networks
docker network ls

# Create a user-defined bridge network
docker network create my-network

# Inspect network details
docker network inspect my-network

# Connect a running container to a network
docker network connect my-network my-container

Here is a comparison of Docker’s built-in 네트워크 drivers:

Bridge Networks in Practice

The bridge 네트워크 is Docker’s default driver. When Docker starts, it creates a virtual bridge called docker0 on the host and assigns containers IPs from the 172.17.0.0/16 subnet by default.

The default bridge has limitations: no automatic DNS 해상도, and all containers are connected with no isolation. User-defined bridges solve these problems:

docker network create my-app-net

docker run -d --name web --net my-app-net nginx
docker run -d --name api --net my-app-net node:18

Containers on the same user-defined bridge can resolve each other by container name:

# From the api container, this resolves to web's IP
ping web

Port publishing maps a host port to a container port via iptables DNAT rules:

# Map host port 8080 to container port 80
docker run -p 8080:80 nginx

Host and Overlay Networks

Host 네트워크

With --network host, the container shares the host’s 네트워크 stack directly — no NAT, no virtual interfaces, and minimal latency. This is useful for 성능 benchmarking or applications that need to 모니터 host interfaces. However, there is no 네트워크 isolation: the container can bind to any host port and potentially interfere with other services.

# docker-compose.yml
services:
  benchmark:
    image: tool:latest
    network_mode: "host"

Overlay Networks

Overlay networks enable communication across multiple Docker hosts. In Swarm mode, creating an overlay 네트워크 automatically distributes it to all nodes:

docker network create -d overlay --attachable my-overlay

Under the hood, overlay networks use VXLAN encapsulation to wrap container packets, allowing them to traverse physical 네트워크 boundaries. Traffic can be encrypted with IPsec using the --opt encrypted flag. The 성능 overhead is approximately 50 bytes per packet and 5–10% throughput reduction.

DNS 해상도 and Service Discovery

Docker runs an embedded DNS 서버 at 127.0.0.11 inside every container. This 서버 resolves container names to IP addresses on user-defined bridge and overlay networks. The default bridge does not provide DNS 해상도 — you must use --link (legacy) or switch to a user-defined bridge.

In Swarm mode, Docker DNS provides round-robin 해상도 for services with multiple replicas:

# Create a service with 3 replicas
docker service create --name api --replicas 3 --network my-overlay my-api:latest

# Other containers resolve "api" to one of the 3 replicas via DNS round-robin

Custom DNS 설정 can be applied per container:

docker run --dns 8.8.8.8 --dns-search example.com nginx

Port Mapping and Security Isolation

Port mapping translates host ports to container ports. The -p flag accepts the format hostPort:containerPort/protocol:

# Multiple ports, specific interface binding
docker run -p 127.0.0.1:8080:80 -p 443:443 nginx

For 네트워크 isolation, Docker provides several mechanisms:

• Internal networks (--internal) — containers cannot access the internet.
• No 네트워크 (--network none) — only loopback, maximum isolation.
• Separate bridges — keep containers on different user-defined bridges based on trust levels.

Docker does not have built-in 네트워크 policies like Kubernetes. For fine-grained control, use iptables, firewalld, or third-party plugins such as Calico, Weave, or Cilium.

Docker Compose Networking Patterns

Docker Compose creates a user-defined bridge 네트워크 for each project (<project>_default). You can define multiple custom networks in the Compose file to separate concerns:

services:
  web:
    image: nginx
    networks:
      - frontend
      - backend
  db:
    image: postgres
    networks:
      - backend
  redis:
    image: redis
    networks:
      - backend

networks:
  frontend:
  backend:

This pattern separates the public-facing web tier from the internal data tier. The web service connects to both networks, while db and redis are only accessible on the internal backend 네트워크.

For connecting to pre-existing networks (e.g., a shared monitoring 네트워크), use external networks:

networks:
  monitoring:
    external: true

When scaling services, each replica gets its own container on the same 네트워크. Use depends_on with healthcheck and condition to ensure service readiness, rather than relying on start order alone.

Conclusion

Docker’s networking model provides flexible, secure, and performant options for container communication. Start with user-defined bridge networks for single-host multi-container applications — they offer automatic DNS 해상도 and better isolation than the default bridge. For multi-host deployments, use overlay networks with Docker Swarm.

When designing your 네트워크 topology:

1. Prefer DNS-based service discovery over hardcoded IP addresses.
2. Use separate bridge networks to isolate tiers based on trust levels.
3. Choose host networking only when latency or 인터페이스 access is critical.
4. Leverage Compose 네트워크 definitions to make your infrastructure declarative and reproducible.

Debug 네트워크 issues with docker network inspect, docker exec into containers to run ip addr and tcpdump, and check firewall rules for cross-host connectivity problems. With these fundamentals in place, you can build container networks that are both powerful and easy to manage.