Docker Network
Docker networking is the virtual networking layer that determines how containers talk to each other and to the outside world. Each container starts in an isolated network namespace, and Docker networks selectively reconnect the communication paths it needs.
βΆArchitecture Diagram
π StructureDashed line animations indicate the flow direction of data or requests
Real applications are not one isolated process. Web containers call APIs, APIs talk to databases, and services need to discover one another even though container IP addresses can change across restarts. If all containers can talk to everything by default, security boundaries also collapse quickly.
Early Docker linked containers by injecting peer IP information directly, but that approach became fragile as topologies grew. User-defined networks improved the model by adding built-in DNS and clearer isolation rules. Overlay networking later extended that abstraction across multiple hosts.
Docker networking changes behavior through drivers. Bridge is the standard same-host mode, and user-defined bridge networks are especially important because Docker's built-in DNS turns container names into hostnames. The default bridge behind `docker0` is Docker's base network interface, but user-defined bridges give cleaner service discovery and isolation controls. Host mode uses the host network stack directly, so it removes much of the NAT layer that normally translates between container and external addressing, but it also brings back direct port-collision risk. Overlay networking uses VXLAN, an extra virtual network layer stretched across hosts, so containers on different machines can behave as if they share one logical network. In practice, the driver choice is a decision about naming, isolation, and multi-host reach.
Docker networking and Docker volumes both open selective paths across container isolation, but for different targets. Networking opens communication paths. Volumes open data paths. Even inside networking, bridge and host mode reflect a tradeoff between stronger isolation and more direct host-level access.
In Compose-based projects, user-defined bridge networks are often the default because services can refer to each other by name such as `db` or `api`. Port publishing is only needed for traffic entering from outside the container world. Internal service-to-service traffic does not need those published ports as long as the services share a network.