Connecting containers to multiple networks in Docker - Step-by-Step Execution

Process Flow - Connecting containers to multiple networks

Container

Container

↓

frontend-net

172.18.0.0/16

↓

Container

"nginx"

A container can connect to multiple Docker networks simultaneously. The 'app' container bridges both frontend-net and backend-net, while nginx and postgres are isolated to their respective networks. This creates network segmentation — nginx cannot reach postgres directly.

Execution Sample

Docker

# Create two networks
docker network create frontend-net
docker network create backend-net

# Start containers on specific networks
docker run -d --name nginx --network frontend-net nginx
docker run -d --name postgres --network backend-net postgres
docker run -d --name app --network frontend-net myapp

# Connect app to the second network
docker network connect backend-net app

# Verify: app can reach both, nginx cannot reach postgres
docker exec app ping -c1 nginx       # SUCCESS
docker exec app ping -c1 postgres    # SUCCESS
docker exec nginx ping -c1 postgres  # FAILS - different network

Creates two isolated networks, places containers on them, then connects the 'app' container to both networks so it can communicate with all services.

Process Table

Step	Command	Container	Networks After Step	Can Reach
1	docker network create frontend-net	-	frontend-net exists (empty)	-
2	docker network create backend-net	-	backend-net exists (empty)	-
3	docker run --network frontend-net nginx	nginx	frontend-net: [nginx]	nginx: nothing yet
4	docker run --network backend-net postgres	postgres	backend-net: [postgres]	postgres: nothing yet
5	docker run --network frontend-net app	app	frontend-net: [nginx, app]	app↔nginx ✓ | app↔postgres ✗
6	docker network connect backend-net app	app	frontend-net: [nginx, app], backend-net: [postgres, app]	app↔nginx ✓ | app↔postgres ✓ | nginx↔postgres ✗

💡 After step 6, 'app' has two network interfaces — one IP on frontend-net (172.18.0.x) and one on backend-net (172.19.0.x). Containers on the same network resolve each other by name via Docker's built-in DNS.

Status Tracker

Container	frontend-net IP	backend-net IP	Total Networks
nginx	172.18.0.2	-	1
postgres	-	172.19.0.2	1
app (after step 5)	172.18.0.3	-	1
app (after step 6)	172.18.0.3	172.19.0.3	2

Key Moments - 3 Insights

Why can't nginx reach postgres even though 'app' is connected to both networks?

Docker network isolation is per-container, not transitive. nginx is ONLY on frontend-net. postgres is ONLY on backend-net. Even though 'app' bridges both, it doesn't act as a router — nginx's packets never leave frontend-net. This is the core security benefit: database containers stay hidden from public-facing services.

What happens when you 'docker network connect' a running container?

Docker adds a new virtual network interface to the container at runtime — no restart needed. The container gets an additional IP address on the new network. Looking at the execution_table row for step 6: 'app' goes from 1 network to 2 networks instantly. You can verify with 'docker inspect app' which shows both networks in the NetworkSettings.

How does DNS resolution work when a container is on multiple networks?

Docker's embedded DNS resolves container names within each network independently. When 'app' pings 'nginx', DNS resolves to nginx's frontend-net IP (172.18.0.2). When 'app' pings 'postgres', DNS resolves to postgres's backend-net IP (172.19.0.2). The container's routing table determines which interface to use based on the destination IP subnet.

Visual Quiz - 3 Questions

After step 6 in the execution table, which container(s) can communicate with BOTH nginx and postgres?

A nginx — it's on the same host

B app — it's connected to both networks

C postgres — Docker DNS resolves all names

D All containers — they share the Docker daemon

💡 Hint

Check the 'Can Reach' column in step 6. Only the container present on BOTH networks can communicate with containers on either network.

Looking at the variable tracker, how many IP addresses does the 'app' container have after step 6?

A 1 — containers can only have one IP

B 2 — one per connected network

C 3 — one per network plus a loopback

D 0 — Docker uses names not IPs

💡 Hint

Check the variable_tracker row for 'app (after step 6)' — count the non-empty IP columns.

If you run 'docker network disconnect frontend-net app', what changes in the execution table?

A app loses access to both nginx and postgres

B app keeps access to nginx but loses postgres

C app loses access to nginx but keeps postgres

D Nothing changes — disconnect only works on stopped containers

💡 Hint

Disconnecting from frontend-net removes app's interface on that network. Check which container is on frontend-net (nginx) vs backend-net (postgres).

Concept Snapshot

docker network create <name>       # Create isolated network
docker run --network <name> <img>   # Start container on network
docker network connect <net> <ctr>  # Add running container to network
docker network disconnect <net> <ctr> # Remove container from network

Key rule: Containers only reach others on the SAME network.
Multi-network containers bridge isolated segments.

Full Transcript

Docker allows containers to connect to multiple networks simultaneously, enabling network segmentation. You create separate networks (e.g., frontend-net and backend-net), place containers on specific networks, and use 'docker network connect' to attach a container to additional networks at runtime. This gives the connected container IP addresses on each network and the ability to communicate with containers on any of its networks. Crucially, containers on different networks cannot communicate directly — even if a third container bridges both networks, it does not act as a router. This isolation is the foundation of Docker's network security model, keeping database containers hidden from public-facing services while allowing application containers to bridge the gap.