docker networkCreate and manage container networks
docker network manages the virtual networks containers attach to. On a user-defined bridge network, containers get their own subnet, reach each other by name through Docker's built-in DNS, and are isolated from containers on other networks. It's how an API finds its database without hard-coded IPs.
docker network ls | create | inspect | connect | disconnect | rm | prune [OPTIONS]You're setting up an API, a database and a cache on one host and want them on their own private network.
docker networkThe network management command group.
A bridge network is a Linux bridge on the host (docker0 for the default one, br-<id> for yours) with its own subnet. Each container gets a network namespace and a veth pair: eth0 inside, the other end plugged into the bridge, plus an IP from the subnet. Traffic out to the world is masqueraded (source NAT) by iptables or nftables rules that dockerd writes; each -p adds a DNAT rule from the host port to the container IP. On user-defined networks every container's /etc/resolv.conf points at 127.0.0.11, an embedded DNS server inside dockerd that answers with the IPs of containers by name, network alias or Compose service name, and forwards everything else to the host's resolvers. The legacy default bridge has no such name resolution. Isolation rules drop traffic between different bridge networks.
Each container gets a veth pair into a Linux bridge; Docker's DNS turns names into IPs and NAT handles published ports.
docker network create shop made a Linux bridge with the subnet 172.20.0.0/16. The bridge holds the gateway address, 172.20.0.1.
lsList networks: ID, name, driver, scopecreate NAMENew network (bridge by default)--subnet / --gatewayPin the address range (avoid clashes with VPN/VPC ranges)--internalNo route to the outside world, containers onlyinspect NAMESubnet, gateway, options and attached containers with their IPsconnect NET CONTAINERAttach a running container to another network (--alias adds a DNS name)disconnect NET CONTAINERDetach it againrm NAME / pruneDelete one network / all unused onesdocker run --network hostShare the host's network stack (no isolation, no -p needed)docker run --network noneLoopback only: no network at allHard-coding container IPs (DB_HOST=172.17.0.3)IPs are handed out on start and change when containers are recreated.
Use a user-defined network and container or service names (DB_HOST=db)Expecting names to resolve on the default bridge networkThe default bridge has no embedded DNS for container names (only the deprecated --link).
docker network create app and run everything with --network appUsing --network host to 'fix' connectivityIt removes network isolation entirely, ports clash with the host's, and -p is ignored.
Put the containers on a shared user-defined networkLetting Docker pick subnets on hosts connected to a VPN or VPCAuto-chosen 172.x ranges can overlap real networks, silently breaking routes to them.
Set default-address-pools in daemon.json, or --subnet per networkTry these on a Linux machine of your own. Each task has a hint and a solution.
Create a network called backend with subnet 10.50.0.0/24, start redis:7-alpine on it named cache2 without publishing any port, then ping it by name from a throwaway container on the same network.
Look at the networking of your own sandbox container: list its interfaces briefly and show which DNS server it uses.
Write the iptables command that shows the DNAT rules Docker created for published ports.
docker networkCreate and manage container networks
docker network manages the virtual networks containers attach to. On a user-defined bridge network, containers get their own subnet, reach each other by name through Docker's built-in DNS, and are isolated from containers on other networks. It's how an API finds its database without hard-coded IPs.
docker network ls | create | inspect | connect | disconnect | rm | prune [OPTIONS]You're setting up an API, a database and a cache on one host and want them on their own private network.
docker networkThe network management command group.
A bridge network is a Linux bridge on the host (docker0 for the default one, br-<id> for yours) with its own subnet. Each container gets a network namespace and a veth pair: eth0 inside, the other end plugged into the bridge, plus an IP from the subnet. Traffic out to the world is masqueraded (source NAT) by iptables or nftables rules that dockerd writes; each -p adds a DNAT rule from the host port to the container IP. On user-defined networks every container's /etc/resolv.conf points at 127.0.0.11, an embedded DNS server inside dockerd that answers with the IPs of containers by name, network alias or Compose service name, and forwards everything else to the host's resolvers. The legacy default bridge has no such name resolution. Isolation rules drop traffic between different bridge networks.
Each container gets a veth pair into a Linux bridge; Docker's DNS turns names into IPs and NAT handles published ports.
docker network create shop made a Linux bridge with the subnet 172.20.0.0/16. The bridge holds the gateway address, 172.20.0.1.
lsList networks: ID, name, driver, scopecreate NAMENew network (bridge by default)--subnet / --gatewayPin the address range (avoid clashes with VPN/VPC ranges)--internalNo route to the outside world, containers onlyinspect NAMESubnet, gateway, options and attached containers with their IPsconnect NET CONTAINERAttach a running container to another network (--alias adds a DNS name)disconnect NET CONTAINERDetach it againrm NAME / pruneDelete one network / all unused onesdocker run --network hostShare the host's network stack (no isolation, no -p needed)docker run --network noneLoopback only: no network at allHard-coding container IPs (DB_HOST=172.17.0.3)IPs are handed out on start and change when containers are recreated.
Use a user-defined network and container or service names (DB_HOST=db)Expecting names to resolve on the default bridge networkThe default bridge has no embedded DNS for container names (only the deprecated --link).
docker network create app and run everything with --network appUsing --network host to 'fix' connectivityIt removes network isolation entirely, ports clash with the host's, and -p is ignored.
Put the containers on a shared user-defined networkLetting Docker pick subnets on hosts connected to a VPN or VPCAuto-chosen 172.x ranges can overlap real networks, silently breaking routes to them.
Set default-address-pools in daemon.json, or --subnet per networkTry these on a Linux machine of your own. Each task has a hint and a solution.
Create a network called backend with subnet 10.50.0.0/24, start redis:7-alpine on it named cache2 without publishing any port, then ping it by name from a throwaway container on the same network.
Look at the networking of your own sandbox container: list its interfaces briefly and show which DNS server it uses.
Write the iptables command that shows the DNAT rules Docker created for published ports.