How Docker Containers Talk: No, They Don’t Use WhatsApp 🛜

Till now, we’ve learned how to build Docker images, create containers, write Dockerfiles, and attach volumes. But have you ever wondered how two containers actually talk to each other? And why do they even need to talk? Well, containers may not have feelings, but they definitely need friends to share information with 😄. For example, a backend application container often needs to communicate with a database container to fetch data. So let’s see how these containers communicate with each other without using WhatsApp or any other social media!

Why do they need to talk ? 🧐

Containers need to communicate because most applications are made up of multiple components that rely on each other. A single container usually can't do everything. For example, a backend application container needs to connect to a database container to store or retrieve data. Similarly, a frontend container might communicate with an API container to get user information or handle requests.
Therefore, container communication is crucial for them to function together as one complete application.

Docker Network and Their Types

We usually start by writing a Dockerfile, then we build an image, and finally we create a container from that image. But what many people don’t realize is that every container automatically gets its own IP address, even if we don’t explicitly configure any network. Docker takes care of this by assigning containers to a default network.

Docker mainly provides these types of networks:

• Bridge

• Host

• None

• Overlay

Bridge Network

The Bridge network is the default network provided by Docker. Whenever we create a container, Docker automatically assigns it an IP address through this network

To view the default network of any container, inspect it.

docker inspect mycontainer

This is the information about the container having an IP address, without creating any specific network

To get available networks

docker network ls

Host Network

In Host Network mode, a Docker container does not get its own private network. Instead, it shares the host machine’s network directly.

What this means:

1. The container uses the host’s IP address.

2. The container cannot have its own port mapping.

3. You cannot run multiple containers on the same port, because the host can only have one process per port.

docker run -itd --name mycontainer -p 80 --network=host newimage:v1

Now, if you create another container using port 80, it will exit immediately.

When using Host Network, a container shares the host machine’s network, so it doesn’t have a separate IP. All traffic goes through the EC2 instance’s IP address

None Network

The None network in Docker provides complete network isolation. When a container is run with the none network:

• It does not get an IP address.

• It cannot communicate with other containers or the host.

• All network traffic is completely blocked.

Use Cases

• Security-sensitive containers: For workloads that should not be exposed to any network.

• Internal scripts or jobs: Containers running tasks that do not require external access.

• Testing or debugging: Simulating network isolation to test container behavior.

docker run --name myContainer --network=none myimage:v1

Overlay network

The Overlay network is used when containers need to talk to each other across different Docker hosts (servers). Unlike Bridge or Host networks, which only work on one machine, Overlay lets containers on different physical or virtual servers communicate as if they were on the same network.

This concept becomes clearer when we look at Docker Swarm. Refer to the related article on our blog for more details.

Connecting Docker Containers to Multiple Networks

Suppose we have two containers: container1 with IP 172.7.0.2 and container2 with IP 172.7.0.3. We could connect them using the --link option. However, there’s a limitation: if either container is deleted or crashes, we would need to re-establish the link manually.

This approach may work for just two containers, but imagine a scenario with 10 or more containers—manually linking each one would be impractical.

To solve this problem, we can create a user-defined network. By connecting all containers to this network, they can communicate automatically using container names, and links are preserved even if containers are restarted or recreated. This is the recommended approach for reliable and scalable container communication.

To Link two containers manually

docker run -itd --name <container1Name> -p 1100:8080 --link <container2Name> <imageNameofContainer1Name>

Now , lets see how to connect by user-defined network

Create two custom Docker networks.

docker network create network1
docker network create network2

Create two custom containers

docker run --name container1 myimage:v1
docker run --name container2 myimage:v1

Connect both networks to each container.

docker network connect network1 container1
docker network connect network2 container1

docker network connect network1 container2
docker network connect network2 container2

To get into container and check whether containers are communicating or not

docker exec -it container1 bash
#After getting inside to container 
ping <ipAddress of container2>

Once the containers are connected to the same network, you can verify connectivity by observing network packets or by successfully pinging each container.

Common Issue: ping: not found

When you try to ping another container from inside a container, you may sometimes see this error

This doesn’t mean networking is broken — it usually means the container doesn’t have the ping utility installed

If your container is Ubuntu / Debian

apt update
apt install iputils-ping -y

Conclusion

Understanding how Docker containers communicate is important for building real-time, scalable applications. Docker networking—using Bridge, Host, None, and Overlay networks—helps containers talk to each other smoothly. Instead of manually linking containers, using user-defined networks makes communication easier, more reliable, and automatically maintained even after restarts. With these concepts, you can confidently build multi-container applications that work together seamlessly.

If you found this guide useful, please like ❤️, comment, and share your thoughts or questions. Stay tuned for the next part, where we'll explore advanced Docker concepts and practices.

Thank you,
Yours, Rama Grandhi