How one container is communicating with another container - Docker Networking

When I first started working with Docker, I thought containers were just lightweight virtual machines. Running a single container was easy, but the real challenge began when multiple containers needed to communicate with each other.

For example:

• How does a frontend container talk to a backend container?
• How does an application container connect to a database container?
• How can we prevent unauthorized containers from accessing sensitive services?

Understanding Docker networking is crucial because every modern application consists of multiple services that need to communicate securely.

In this article, we’ll explore how container networking works, how containers discover each other, and the best practices for building secure container networks.

Why Do Containers Need Networking?

Imagine a simple application:

Frontend → Backend API → Database

Each component runs inside its own container.

Without networking:

• Frontend cannot reach Backend
• Backend cannot reach Database
• Services become isolated

Docker networking provides the communication layer that allows containers to discover and talk to each other.

Understanding Docker’s Default Network

When Docker is installed, it automatically creates a network called:

docker network ls

Output:

NETWORK ID     NAME      DRIVER
xxxxxxx        bridge    bridge

This bridge network acts like a virtual switch.

When containers are attached to this network:

• Docker assigns them private IP addresses
• Containers can communicate internally
• Traffic remains isolated from the host network

How One Container Talks to Another

Let’s create two containers:

docker run -d --name app nginx
docker run -it --name client ubuntu bash

Now, from the client container:

ping app

Will it work?

❌ No.

Containers running on the default bridge network cannot automatically resolve container names.

This is where custom networks become important.

User-Defined Bridge Networks

Create a custom network:

docker network create my-network

Run containers on this network:

docker run -d \
--name backend \
--network my-network \
nginx

docker run -it \
--name frontend \
--network my-network \
ubuntu bash

Now inside the frontend container:

ping backend

Result:

PING backend (172.x.x.x)

Docker automatically provides DNS-based service discovery.

Instead of remembering IP addresses, containers can communicate using container names.

This is one of the biggest advantages of user-defined networks.

Real-World Example: Application and Database

Suppose we have:

Container A → Spring Boot App
Container B → MySQL Database

Create network:

docker network create app-network

Run MySQL:

docker run -d \
--name mysql-db \
--network app-network \
-e MYSQL_ROOT_PASSWORD=password \
mysql:8

Run Application:

docker run -d \
--name java-app \
--network app-network \
java-app:1.0

Application connection string:

spring.datasource.url=jdbc:mysql://mysql-db:3306/mydb

Notice:

mysql-db

is the container name, not an IP address.

Docker’s internal DNS handles the resolution automatically.

How Docker Networking Works Internally

Behind the scenes, Docker creates:

• Virtual Ethernet interfaces (veth pairs)
• Network namespaces
• Linux bridges
• Internal DNS services

Every container receives:

Container Network Namespace
       ↓
Virtual Interface
       ↓
Docker Bridge
       ↓
Host Network

This isolation is what makes containers lightweight and secure.

Common Docker Network Types

1. Bridge Network

Default option for standalone containers.

docker network create my-network

Best for:

• Single host deployments
• Development environments

2. Host Network

docker run --network host nginx

Container shares the host’s network stack.

Get Ankitha Rao’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Pros:

• Better performance

Cons:

• Reduced isolation
• Security concerns

3. None Network

docker run --network none nginx

No networking at all.

Best for:

• Highly restricted workloads
• Security-sensitive applications

4. Overlay Network

Used in Docker Swarm.

Allows communication across multiple hosts.

Useful for:

• Multi-node deployments
• Distributed applications

Building Secure Container Networks

Many engineers focus on container security but overlook network security.

A secure container environment starts with network segmentation.

Security Practice #1: Use Custom Networks

Avoid putting every container on the default bridge network.

Instead:

docker network create frontend-network
docker network create backend-network

Separate services by function.

Security Practice #2: Limit Service Exposure

Avoid exposing internal services publicly.

Bad:

docker run -p 3306:3306 mysql

Now anyone can attempt database connections.

Better:

docker run \
--network backend-network \
mysql

Only application containers can access it.

Security Practice #3: Separate Frontend and Backend

Example architecture:

Internet
    ↓
Frontend Network
    ↓
API Container
    ↓
Backend Network
    ↓
Database Container

Database is never directly exposed.

This significantly reduces the attack surface.

Security Practice #4: Use Least Privilege Networking

Not every container needs access to every service.

Example:

Frontend → API
API → Database

Frontend ✖ Database

Restrict communication paths wherever possible.

Security Practice #5: Encrypt Sensitive Traffic

For production workloads:

• HTTPS between services
• TLS-enabled databases
• Service mesh solutions such as Istio

Never assume internal traffic is automatically secure.

Docker Compose Example

Docker Compose makes networking easier.

version: '3'

services:
  frontend:
    image: nginx
    networks:
      - frontend
  backend:
    image: my-api
    networks:
      - frontend
      - backend
  database:
    image: mysql
    networks:
      - backend
networks:
  frontend:
  backend:

Result:

Frontend ↔ Backend
Backend ↔ Database
Frontend ✖ Database

Exactly the network segmentation we want.

Key Takeaways

Docker networking is more than just exposing ports.

To build secure and scalable containerized applications:

✅ Use user-defined bridge networks

✅ Communicate using container names instead of IP addresses

✅ Isolate services into separate networks

✅ Avoid exposing databases directly

✅ Follow least-privilege networking principles

✅ Encrypt sensitive traffic in production

The next time you run multiple containers, don’t just ask whether they can communicate — ask whether they should.

Happy learning !!!