What does starting a container with Docker's --network container:<name> flag do? Explain exactly what is shared and what is not shared between the two containers, and give a case where you would use it.

## The mechanism A container's network stack is a Linux network namespace: its own interfaces, routing table, iptables rules, socket tables and loopback. Normally `docker run` creates a fresh one and wires a veth pair to a bridge. `--network container:web` skips creation and **enters the existing namespace** of the named container. The two processes now look, to the kernel network stack, like they are on the same machine. Concretely, they share: the IP address and MAC, all interfaces including `lo`, the routing table, the port/socket space, and any published port mappings. They do not share: filesystem (each still runs its own image with its own mounts), processes (separate PID namespaces unless you also pass `--pid container:web`), users, IPC, or resource limits — memory and CPU cgroups remain per-container, which is precisely what makes a sidecar independently limitable. ## Consequences that show up in practice **Localhost becomes the communication channel.** The sidecar talks to the app over `127.0.0.1`, which is fast and never leaves the host, and the app needs no configuration to accept it. This is exactly the model a Kubernetes pod generalises — containers in a pod share a network namespace for the same reason — though the pod abstraction itself belongs to orchestration, not to Docker. **Port conflicts are real.** One port space means two servers cannot both bind 8080. Sidecars must be assigned distinct ports. **Publishing belongs to the owner.** Because the namespace and its NAT rules were established when the first container started, `-p` on the joining container is refused. Any port a sidecar exposes must be published up front by the owning container, which is easy to forget when you add an exporter or proxy later. **Lifecycle coupling.** The joining container's network exists only as long as the owner does. Restart the owner and the joiner keeps running with a dead network stack; the practical rule is that the sidecar restarts with the app, and Compose users express it with `network_mode: "service:app"` plus `depends_on`. ## Where it earns its place *Debugging slim images.* Modern images are distroless or scratch-based, with no shell, no curl, no tcpdump. Attaching a toolbox container to the app's namespace gives you the app's exact network view — same interfaces, same DNS resolver, same conntrack — without adding tools to the production image. This is the single strongest argument for knowing the flag. *Sidecar proxies and adapters.* A TLS-terminating proxy, an authentication shim, or a metrics exporter that scrapes 127.0.0.1 all fit. Traffic interception via the sidecar's iptables rules also works because iptables state lives in the shared namespace. *VPN or egress gateways.* One container establishes a tunnel and other containers join its namespace so all their traffic exits through it, with no per-application configuration. ## Comparison with the alternatives Against a shared user-defined network, namespace sharing is tighter: same IP, loopback communication, no service discovery needed, but also no isolation between the two — a compromised sidecar sees and can manipulate the app's network stack, including binding ports and rewriting iptables. Against `--network host`, it is much narrower: the app's namespace is not the host's, so host services and host ports are still separate. The judgment call is coupling. Use it when two processes genuinely form one network endpoint or when you need someone else's exact network view; use a shared network when the containers are independent services that merely talk.