Learn how containers communicate with each other and how to keep data alive even after containers are removed.
Modern applications rarely run as a single container. A typical application might include a web application, a database, a cache layer, and background workers. For these services to work together, containers need a reliable way to communicate and share data.
In this article, we’ll learn:
- How Docker networking works
- How containers discover each other
- Docker network drivers
- Persistent storage with Docker volumes
- Essential networking and volume commands
- A real-world multi-container example
By the end, we’ll understand two of the most important concepts in Docker: networking and data persistence.
Why Docker Networking Matters
Every container runs inside its own isolated network namespace.
This isolation improves security and prevents conflicts, but it also creates an important challenge:
If containers are isolated, how does a web application connect to a database?
Imagine a web application running inside one container and MongoDB running inside another. Without networking, they cannot communicate.
Docker solves this problem using Docker Networks.
A Docker network allows containers to communicate with each other while remaining isolated from unrelated containers.
Web App Container
|
v
Docker Network
|
v
Database Container
Enter fullscreen mode Exit fullscreen mode
Without a shared network, containers cannot easily find or communicate with each other.
Docker Network Drivers
Docker supports several network drivers, but most developers primarily use three.
Bridge Network
A bridge network creates a private virtual network on the Docker host.
Containers connected to the same bridge network can communicate with each other securely.
Create a custom bridge network:
docker network create my-app-network
Enter fullscreen mode Exit fullscreen mode
Benefits of bridge networks:
- Container-to-container communication
- Isolation from other applications
- Built-in DNS resolution
- Easy management
For most Docker projects, a user-defined bridge network is the recommended choice.
Host Network
With the host driver, the container shares the host machine’s network stack directly.
docker run --network host nginx
Enter fullscreen mode Exit fullscreen mode
Advantages:
- Slightly better networking performance
- No port mapping required
Disadvantages:
- Reduced isolation
- Potential port conflicts
- Less flexibility
For most applications, bridge networks are the better option.
None Network
The none driver completely disables networking.
docker run --network none alpine
Enter fullscreen mode Exit fullscreen mode
A container using this driver:
- Cannot access the internet
- Cannot communicate with other containers
- Cannot accept incoming connections
This is useful for highly restricted workloads that require no network access.
The Most Important Feature: Service Discovery
One of Docker’s most powerful networking features is built-in DNS resolution.
Instead of connecting containers by IP address, we can connect them using container names.
The Problem with IP Addresses
Container IP addresses are assigned dynamically.
If a container restarts, its IP address can change.
Hardcoding IP addresses creates fragile configurations that eventually break.
For example:
192.168.1.25 → MongoDB
Enter fullscreen mode Exit fullscreen mode
If MongoDB restarts and receives a new IP address, the application can no longer connect.
The Better Approach
Create a custom network:
docker network create my-app-network
Enter fullscreen mode Exit fullscreen mode
Run MongoDB:
docker run -d
--name mongo
--network my-app-network
mongo
Enter fullscreen mode Exit fullscreen mode
Run Mongo Express:
docker run -d
--name mongo-express
--network my-app-network
-e ME_CONFIG_MONGODB_SERVER=mongo
-p 8081:8081
mongo-express
Enter fullscreen mode Exit fullscreen mode
Notice this environment variable:
ME_CONFIG_MONGODB_SERVER=mongo
Enter fullscreen mode Exit fullscreen mode
Mongo Express connects to MongoDB using the container name.
Docker automatically resolves:
mongo → container IP address
Enter fullscreen mode Exit fullscreen mode
This feature is called service discovery.
Instead of relying on changing IP addresses, containers communicate using stable names.
Essential Docker Network Commands
List all networks:
docker network ls
Enter fullscreen mode Exit fullscreen mode
Create a network:
docker network create my-app-network
Enter fullscreen mode Exit fullscreen mode
Inspect a network:
docker network inspect my-app-network
Enter fullscreen mode Exit fullscreen mode
Connect a running container:
docker network connect my-app-network my-container
Enter fullscreen mode Exit fullscreen mode
Disconnect a container:
docker network disconnect my-app-network my-container
Enter fullscreen mode Exit fullscreen mode
Remove a network:
docker network rm my-app-network
Enter fullscreen mode Exit fullscreen mode
These commands are the foundation of Docker networking and are frequently used when troubleshooting multi-container applications.
Why Docker Volumes Matter
Containers are designed to be disposable.
If a container is removed, any data stored inside its writable layer is lost forever.
For applications such as databases, this is a major problem.
Imagine storing customer information in MongoDB and then deleting the container.
Without persistent storage:
Container removed = Data lost
Enter fullscreen mode Exit fullscreen mode
This is where Docker Volumes become essential.
Docker Volumes allow data to exist independently from containers.
Even if a container is removed and recreated, the data remains intact.
Types of Docker Storage
Docker provides multiple ways to persist data.
Named Volumes
Named volumes are the recommended approach for most production workloads.
Create a volume:
docker volume create mongo-data
Enter fullscreen mode Exit fullscreen mode
Use the volume:
docker run -d
--name mongo
-v mongo-data:/data/db
mongo
Enter fullscreen mode Exit fullscreen mode
Benefits:
- Managed by Docker
- Portable across environments
- Easy backups and maintenance
- Cleaner configuration
For databases and production applications, named volumes are usually the best choice.
Bind Mounts
Bind mounts connect a specific host directory to a container.
Example:
docker run -d
-v /home/user/data:/data/db
mongo
Enter fullscreen mode Exit fullscreen mode
Benefits:
- Direct access to files from the host
- Great for development workflows
- Easy editing of source code
Drawbacks:
- Depends on host filesystem paths
- Less portable
- Can introduce permission issues
Bind mounts are commonly used during development, while named volumes are preferred for production workloads.
Understanding Volume Mapping
Volume syntax follows this format:
-v source:destination
Enter fullscreen mode Exit fullscreen mode
Example:
-v mongo-data:/data/db
Enter fullscreen mode Exit fullscreen mode
mongo-data → Host side
/data/db → Container side
Enter fullscreen mode Exit fullscreen mode
If the container writes data to /data/db, that data is stored in the Docker volume named mongo-data.
This is similar to Docker port mapping:
-p 8080:80
Enter fullscreen mode Exit fullscreen mode
8080 → Host port
80 → Container port
Enter fullscreen mode Exit fullscreen mode
The same “host-to-container” concept applies to both networking and storage.
Essential Docker Volume Commands
List all volumes:
docker volume ls
Enter fullscreen mode Exit fullscreen mode
Create a volume:
docker volume create my-volume
Enter fullscreen mode Exit fullscreen mode
Inspect a volume:
docker volume inspect my-volume
Enter fullscreen mode Exit fullscreen mode
Remove a volume:
docker volume rm my-volume
Enter fullscreen mode Exit fullscreen mode
Remove unused volumes:
docker volume prune
Enter fullscreen mode Exit fullscreen mode
⚠️ Use docker volume prune carefully.
It permanently deletes unused volumes and can remove important data if executed without checking first.
A good habit is to review existing volumes before deleting anything.
Building a Real Multi-Container Application
Let’s combine networking and volumes into a realistic example.
Step 1: Create a Network
docker network create my-app-network
Enter fullscreen mode Exit fullscreen mode
Step 2: Create a Volume
docker volume create mongo-data
Enter fullscreen mode Exit fullscreen mode
Step 3: Start MongoDB
docker run -d
--name mongo
--network my-app-network
-v mongo-data:/data/db
mongo
Enter fullscreen mode Exit fullscreen mode
Step 4: Start Mongo Express
docker run -d
--name mongo-express
--network my-app-network
-e ME_CONFIG_MONGODB_SERVER=mongo
-p 8081:8081
mongo-express
Enter fullscreen mode Exit fullscreen mode
What happens here?
- MongoDB stores its data in a persistent volume.
- Mongo Express shares the same Docker network.
- Mongo Express discovers MongoDB using the hostname
mongo. - Data survives container recreation.
- Both services remain isolated from unrelated containers.
This is a real-world pattern used in countless Docker applications.
How Networking and Volumes Work Together
A successful containerized application usually needs both networking and persistence.
Networking provides:
- Communication between services
- Service discovery
- Isolation between applications
Volumes provide:
- Persistent storage
- Data durability
- Independence from container lifecycle
Without networking, services cannot communicate.
Without volumes, important data disappears when containers are removed.
Together, they form the foundation of modern containerized applications.
Final Thoughts
Running a single container is useful, but real-world applications require much more.
A web application needs to communicate with databases, caches, and supporting services. At the same time, important data must survive container restarts, updates, and redeployments.
Docker Networks solve communication challenges through service discovery and isolation.
Docker Volumes solve persistence challenges by separating data from container lifecycles.
These two concepts are fundamental building blocks for everything that comes next:
- Docker Compose
- CI/CD pipelines
- Kubernetes
- Cloud-native applications
Master Docker networking and volumes, and we’ll be well prepared to build and operate real-world containerized applications.