█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/DevOps and Infrastructure/Docker and Containerization/Docker Networking
40 minIntermediate

Docker Networking

After this lesson, you will be able to: Understand Docker networking: bridge, host, container-to-container DNS, port publishing, and the common gotchas.

Most Docker bugs are networking bugs. This lesson explains the model so you can debug them in seconds.

Prerequisites:Docker Compose

The three network modes

Bridge (default): Docker creates a virtual switch on the host. Containers get IPs in a private subnet (172.x). Containers reach each other by name (Docker DNS); host reaches them only via published ports (`-p`). Host: container shares the host's network stack. No isolation; container's port 80 IS the host's port 80. Faster, less isolated; rare in production. None: no networking at all. Used for isolated processing jobs.

Custom networks (the right pattern for groups)

Instead of the default bridge, create your own.

tsx
docker network create my-app-net
docker run -d --name db --network my-app-net postgres
docker run -d --name web --network my-app-net -p 3000:3000 myapp
# Inside web, you can reach db by name:
# psql -h db -U postgres
# Docker DNS resolves 'db' to the right IP.
docker network ls # list networks
docker network inspect my-app-net # see who's on it

Why service-name DNS matters

Without it, container IPs change on every restart. Hardcoding IPs is brittle. On a custom network (or Compose's default), Docker runs a tiny DNS server. Each container looks up other containers by name. Production lesson: never reference containers by IP. Always by name (Docker) or by service (Kubernetes).

Publishing ports: -p and the host firewall

`-p 8080:80` binds host:8080 to container:80. Anyone who can reach the host on 8080 can hit your container. `-p 127.0.0.1:8080:80` binds only to localhost, useful for dev to prevent external access. On a public VPS without a firewall, every `-p` exposes you to the internet. Pair Docker with UFW or a cloud security group. Common UFW gotcha: Docker bypasses UFW by default on Linux. Use Docker's own iptables-aware rules or run a reverse proxy.

Debug networking from inside a container

Drop into a container and test what it can reach.

tsx
docker exec -it web sh
# Inside the container:
ping db # service name resolves?
getent hosts db # explicit DNS lookup
nc -zv db 5432 # can we connect on port 5432?
wget -qO- http://other-service:8080 # actually fetch a URL
# If the container image is slim and has no debugging tools:
docker run --rm -it --network container:web nicolaka/netshoot
# netshoot is a debugging image with curl, dig, nc, tcpdump, etc.
# --network container:web joins the same network as the running 'web' container.

Common mistakes only experienced engineers avoid

Trying to reach containers from the host by container IP. Use published ports. Hardcoding container IPs. Use service names. Trusting UFW to block Docker-published ports on Linux. Docker manipulates iptables directly. Publishing the same port twice (-p 8080:80 from two services). Second one fails to start. Forgetting that `docker network create` creates a network; containers must explicitly join. Old containers don't auto-join.

Quick Check

Two containers on the default bridge network can't reach each other by name. Why?

Pick the most common cause.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Docker Compose
Back to Docker and Containerization
Docker Volumes→