Container Networking
Most important commands to remember
docker network ls— identify available network objects and drivers.docker network inspect— inspect a network’s addresses and attached containers.docker ps— compare running containers with their port mappings.
Commands and flags
| Command or option | Meaning |
|---|---|
docker network ls |
List networks known to the selected engine. |
docker network inspect bridge |
Inspect the existing default bridge network. |
--format '{{json .IPAM.Config}} {{json .Containers}}' |
Show address-management configuration and attached container records as JSON. |
docker ps --format 'table …' |
Show running container names, networks, and port information. |
{{.Names}}, {{.Networks}}, {{.Ports}} |
Docker template fields, not shell variables. |
Tabs separate the table columns. The selected Docker context determines which engine you inspect; on Docker Desktop, the Linux engine normally runs in a VM.
The concepts that matter
1. A container can have its own network view
A typical Linux container network namespace has its own interfaces, addresses, routes, and port bindings. Its loopback address refers to that namespace, not automatically to the host or another container.
Two isolated containers can both listen on port 8080 without conflicting. A conflict appears when they try to claim the same address and port in a shared namespace or the same published host endpoint. Host-network mode changes these assumptions.
2. A bridge joins container interfaces
A bridge network connects participating container interfaces through the engine’s networking setup. Container addresses belong to that network, and routes and policy determine where traffic can go next.
The container address is not necessarily reachable from your laptop directly, particularly when the engine lives inside a VM. Outbound connectivity can use address translation. Inspect the actual network driver rather than assuming every container uses a bridge.
3. Service names and addresses are different tools
User-defined Docker bridge networks provide automatic DNS resolution between their containers. This helps clients use names instead of depending on an address that can change when a container is recreated.
The default bridge does not provide the same automatic container-name resolution behavior. A name resolving successfully also proves neither a listening application nor permitted traffic. DNS, routing, filtering, and the application listener remain separate steps.
4. Publishing a port exposes a host-side entry point
A published port maps a host-side address and port to a container-side port under the engine’s networking rules. It is not the same as documentation in an image declaring that a port is exposed.
The host binding matters: a loopback-only binding and a binding on all host interfaces have different reachability. The application must also listen on a suitable container address. A mapping cannot make a nonexistent listener respond or override every external firewall.
One small example
Optional: inspect the selected test engine. The commands read configuration only and do not create networks or expose ports. The second command assumes the ordinary Linux default bridge exists.
docker network ls
docker network inspect bridge --format '{{json .IPAM.Config}} {{json .Containers}}'
docker ps --format 'table {{.Names}} {{.Networks}} {{.Ports}}'Use the first output to identify the bridge driver, then inspect its subnet and attached container records. An empty attachment object is valid when no container uses that network. Containers on other networks will not appear in that attachment list.
In the final output, compare plain container port declarations with mappings containing a host address and an arrow to a container port. The exact format can vary. This inspection does not send traffic, prove name resolution, or establish external reachability. If bridge is absent under a customized engine configuration, that is a different setup, not proof of failed networking.
Keep this idea: Container networking connects separate network views; names, routes, listeners, and published host ports solve different parts of reachability.