Docker network mystery

When I was learning Docker, I ran this command to create a container:
docker run -d --name my-first-container -p 8080:80 nginx

I knew -d meant the process runs in the background and -p maps the laptop port to Docker. But I had to ask: Why do we actually need to do this?

The answer forced me to understand networking.

The Problem: Isolation
Docker is a wrapper of Linux, using namespaces and c-groups. By default, containers are isolated. They have their own IP addresses, but your laptop network doesn't know about the container's IP. Without a connection between your laptop and the container, you cannot open that container in your browser.

The Solution: The Middleman
You install a Docker engine (like Docker Desktop or OrbStack) on your laptop. That engine acts as the middleman between your laptop and the container. This is why you map the ports. For example, the HTTP port is 80 and your laptop port is 8080. By writing 8080:80, you are saying: If any request comes into the laptop port, send it into container port 80. This is the concept of a Bridge Network.

Three Concepts I've Mastered:

Bridge Network: The default way to connect your laptop to a container using port mapping.

Host Network: In this concept, there is no need to do port mapping because the container uses the host directly.

Overlay Network: What if 10 different containers on 10 different laptops need to work like they exist in the same network? Overlay creates a tunnel on top of all the laptops, so every container behaves like they are in the same laptop.

The Overlay concept is heavily used in Kubernetes. Understanding these basics is how I'm moving toward Mastery in SRE and Platform Engineering! 🚀

Comments

[疏影]

Docker network debugging boils down to five diagnostics:

1. docker network ls then docker network inspect <name> — the JSON tells you subnet, gateway, connected containers, and which containers have aliases. This is the starting point for 90% of 'why can't container X reach container Y'.

2. docker exec <container> nslookup <service> — DNS resolution across bridge, overlay, and custom networks. If nslookup returns the container IP, DNS is healthy. If it fails with 'no such host', you're on the default bridge (which has no DNS) and need to create a user-defined bridge.

3. Overlay networks need a Swarm or a K8s cluster — a single-host Docker daemon cannot create an overlay network because etcd/raft consensus requires a quorum. Use a bridge network for single-host, overlay only when crossing nodes.

4. Port mapping (-p 8080:80) only works for bridge networks. For overlay networks with multi-host, the port is reachable from any node in the Swarm without -p. Mixing -p on overlay creates port conflicts.

5. Network drivers stack: you can attach a single container to multiple networks with docker network connect. This is how you bridge from a service network to a 'db' network without exposing DB ports externally.

6. For ops who need to share files between dev containers and the host Windows file system without -v mount quirks: ScsDriver