Instruction 01-docker-networking: Reading

Docker networking separates three questions that are often confused: where a process listens, which containers can reach it, and whether the host or outside clients can reach it. A process listening on port 8080 inside a container does not automatically create a host port. Containers attached to the same user-defined bridge network can normally communicate directly using the destination container's listening port. Compose also registers service names with Docker's embedded DNS, so a client can request http://gateway:8080 without learning a changing container IP address. DNS visibility is scoped by network membership: a service that does not share a network with the requester should not be treated as directly reachable.

This lab models a segmented application. The client joins only the frontend network. The database joins only the backend network. The gateway joins both and therefore becomes the only service with a network path to each side. The gateway is multi-homed, but Docker does not automatically turn it into a general IP router. It can initiate application-level requests on both networks because it has an interface on each one. The client can resolve and contact gateway, while the gateway can resolve and contact database. The client should not directly resolve or contact database because they share no network.

The backend network is marked internal. This reduces unintended external routing for containers that exist only on that network. It is not an authentication system, an application firewall, or a guarantee that a compromised gateway cannot reach the database. The gateway is intentionally trusted with backend reachability. Production designs must still use authentication, authorization, encryption where appropriate, least-privilege credentials, and application-specific access controls.

Verification should test the complete path rather than DNS in isolation. A successful wget request demonstrates both name resolution and TCP/HTTP connectivity. A failed request is meaningful only after confirming that the client is running, wget exists, and a positive request to gateway succeeds. Otherwise, a stopped client or missing executable could be mistaken for successful isolation. Docker inspection then supplies the structural evidence: the client and database have no shared network, while the gateway appears on both networks. Finally, docker compose port confirms that no host port was published. An EXPOSE instruction or a process listening inside a container would document or create an internal listening port, but neither publishes that port to the host.