Publishing Ports & Traffic Flow

Inside vs Outside

Two different questions with two different answers:

• Container → container (same user-defined network): use the container name and the app's real port - http://api:3000. No -p needed.
• Outside world → container: requires publishing, -p 8080:80.

Browser ──:8080──▶ host ──DNAT──▶ web:80 ──proxy──▶ api:3000
                                  └── shopnet DNS: "api" → 172.19.0.2

Debugging connectivity, in order:

$ docker ps                         # 1. is it running? what's published?
$ docker port web                   # 2. exact mappings
$ docker logs web                   # 3. did the app bind? crash?
$ docker network inspect shopnet    # 4. are both containers members?
$ docker exec web wget -qO- http://api:3000/health   # 5. test from inside

Warning: "Port is already allocated" means another container (or host process) holds the host port. docker ps shows who. Two containers can both listen on container port 80, but only one can own host port 8080.

Goal: Two labs cover this: Free the Port (port conflict on release day) and Connect the Microservices (the default-bridge DNS incident, end to end, with the browser panel showing before/after).