1. Why Connect Containers? (Beginner Explanation)
Real applications are never one container. They are usually:
- A backend
- A database
- A frontend
- A cache
- A message queue
These containers must talk to each other.
Docker makes this easy:
👉 If two containers are in the same network, they can communicate directly.
Example:
backend → database
frontend → backend
No extra setup needed.
2. Visual Understanding: Docker Network = Private LAN
Imagine Docker creates a private LAN inside your computer:
┌────────────────────────────┐
│ mynetwork │
│ │
│ container A <———> container B
│ container C <———> container D
│ │
└────────────────────────────┘
Every container in this network can:
- See each other
- Ping each other
- Communicate using names (Docker DNS)
This is the foundation of multi-container apps.
3. Step 1 — Create a Custom Network
Default network works, but custom networks give Docker DNS, which is super powerful.
Run:
docker network create mynetwork
Docker automatically assigns:
- Subnet
- Gateway
- Internal DNS
Now this network behaves like a private LAN.
4. Step 2 — Run Two Containers in the Same Network
Example: one backend, one database.
Run backend:
docker run -d --name backend --net=mynetwork nginx
Run database:
docker run -d --name database --net=mynetwork redis
Both are now inside mynetwork.
Visual:
mynetwork
│
├── backend (nginx)
└── database (redis)
5. How Do They Talk to Each Other? (Docker DNS Magic)
In a custom network:
👉 Containers can talk using names, not IPs. 👉 Docker acts as a DNS server inside the network.
Example:
Inside backend container:
ping database
Inside database container:
ping backend
This works because Docker internally resolves:
backend → 172.x.x.x
database → 172.x.x.x
No need for static IPs. No need for configuration files.
6. Testing Communication (Beginner-Friendly Example)
Step 1 — Enter backend container:
docker exec -it backend sh
Step 2 — Ping database:
ping database
You will see replies like:
64 bytes from 172.18.0.3: icmp_seq=1 ttl=64 time=0.20 ms
This means:
✔ They are in the same network ✔ They can communicate ✔ Docker DNS is working
7. Real App Example — Node.js Calls Redis
Let’s run a Node app (API server) talking to Redis database.
Run Redis:
docker run -d --name redisdb --net=mynetwork redis
Run Node API:
docker run -d --name api --net=mynetwork node
Inside the Node app, your connection string becomes:
redis://redisdb:6379
Notice:
- No IP
- No port mapping
- Just container name
That’s Docker DNS power.
8. Connect a Running Container to Network (Optional)
If a container is already running, you can attach it:
docker network connect mynetwork backend
Now it becomes part of the network without restarting.
9. 5-Second Visual Summary
Create network → run containers inside it → communicate using names
Or even simpler:
Same network = direct communication
Done.
10. FAQs (SEO-Friendly + Beginner Questions)
Q1: Can containers in different networks talk?
No — unless you manually connect them to the same network.
Q2: Is port-mapping needed inside the same network?
No. Containers talk internally without exposing ports.
Q3: Why do containers use names as DNS?
Docker automatically provides DNS inside custom networks.
Q4: Can I assign static IPs to containers?
Yes, but only inside custom networks (not recommended unless needed).
Q5: What happens if two containers have same name?
Docker will not allow it. Names must be unique.
🏁 Final Words (Your Tone)
Connecting containers is literally the backbone of real Docker apps. And the rule is simple:
“If two containers live in the same network, they already know each other.”
No manual IPs. No complicated setups. Just clean communication using container names.
This is how microservices talk in Docker — simple, fast, visual, predictable.