Introduction
When working with Docker, you quickly realize that containers are stateless and isolated by design.
While this isolation brings consistency and reproducibility, it also introduces challenges in communication and data persistence.
Without properly configured networks, your containers can’t talk to each other.
Without volumes, your data will disappear once a container stops or restarts.
This tutorial will teach you how to:
- Understand Docker network types (
bridge,host,overlay) - Enable inter-container communication
- Persist data using Docker volumes
- Compare
bind mountsandnamed volumes - Configure networks and volumes with
docker-compose - Create and restore volume backups safely
By the end of this guide, you’ll be confident setting up durable, connected container environments for both single-host and multi-node deployments.
Prerequisites
Before you begin, make sure you have:
- A Linux or macOS environment (or Windows with Docker Desktop)
- Docker Engine v24+
- Basic terminal and shell experience
- Internet access for pulling Docker images
Note:
All commands are run from a user withsudoprivileges but not as root.
Usesudowhere necessary.
Step 1 — Understanding Docker Networks
Docker networks allow containers to communicate with each other and with the outside world.
There are several built-in network drivers, each suited for a specific purpose.
You can list available networks with:
docker network ls
Example output:
NETWORK ID NAME DRIVER SCOPE
b1292dd03ea9 bridge bridge local
🔹 The bridge Network (Default)
By default, Docker connects new containers to the default bridge network, which provides NAT-based internet access.
docker run -dit --name web1 nginx
docker exec -it web1 ip a
Each container gets a virtual Ethernet interface (veth) linked to the host’s docker0 bridge.
Create a Custom Bridge
You can create an isolated bridge network where containers can communicate via container names:
docker network create --driver bridge my_bridge
docker run -dit --name nginx1 --network my_bridge nginx
docker run -dit --name nginx2 --network my_bridge alpine sh
docker exec -it nginx2 ping nginx1
✅ Tip:
Containers can resolve each other’s names automatically within the same user-defined bridge.
🔸 The host Network
When you use the host network mode, the container shares the host’s network namespace.
This means no network isolation — it runs as if it were on the host directly.
docker run --rm -d --network host nginx
No port mapping (-p) is required since ports are directly exposed on the host.
⚠️ Warning:
Host networking offers the best performance but reduces isolation and may expose security risks.
🔸 The overlay Network (Multi-host)
Overlay networks enable communication between containers running on different Docker hosts.
They require Docker Swarm mode.
Initialize Swarm:
docker swarm init
Create an attachable overlay network:
docker network create -d overlay --attachable app_overlay
Now any container or service across Swarm nodes can connect to app_overlay.
💡 Overlay uses VXLAN encapsulation to create a virtual network that spans multiple hosts.
🔸 Other Drivers: macvlan and none
- macvlan: Assigns containers real MAC and IP addresses managed by the physical network switch — useful for legacy systems.
- none: Disables networking completely (fully isolated).
Step 2 — Inspecting Real Traffic with tcpdump
To understand how Docker networks route traffic under the hood, use tcpdump on the docker0 interface.
Install tcpdump:
sudo apt install tcpdump -y
Then capture packets:
sudo tcpdump -i docker0
When you ping between containers, you’ll see ICMP traffic being encapsulated and bridged via virtual interfaces.
Step 3 — Theoretical Overview of Docker Networking
Here’s a simplified visualization of how containers connect to each other:
[ Container1 ]---vethX docker0 host network Internet
[ Container2 ]---vethY /
Each container is linked to the host via a veth pair, one end inside the container, the other connected to the bridge on the host.
docker0 acts as a switch, routing packets between all connected containers.
Step 4 — Managing Persistent Data with Docker Volumes
Containers are ephemeral by nature — their filesystem disappears when removed.
To persist data, Docker provides volumes and bind mounts.
🟦 Named Volumes
A named volume is managed entirely by Docker and stored under /var/lib/docker/volumes.
Create one:
docker volume create app_data
Use it in a container:
docker run -d -v app_data:/usr/share/nginx/html nginx
Inspect existing volumes:
docker volume ls
docker volume inspect app_data
🟧 Bind Mounts
Bind mounts link a specific host directory to a path inside the container.
This allows live editing of files without rebuilding the image.
Example:
mkdir -p ~/data
echo "Hello from Docker" > ~/data/index.html
docker run -d -v ~/data:/usr/share/nginx/html -p 8080:80 nginx
Now open http://localhost:8080 — you’ll see the content of your host file.
Step 5 — Comparing Bind Mounts vs Named Volumes
| Feature | Named Volume | Bind Mount |
|---|---|---|
| Performance | Optimized by Docker | Depends on filesystem |
| Security | More controlled | Requires host access |
| Backup | Easier | More complex |
| Flexibility | Low (managed by Docker) | High (any path) |
| Portability | High (Docker-managed) | Low (host-dependent) |
💡 Rule of Thumb:
- Use Named Volumes for production and portability.
- Use Bind Mounts for development and debugging.
Step 6 — Volume Backup and Restore
Even managed volumes need backups.
You can archive volume data into a .tar.gz file using a lightweight container like busybox.
📦 Backup a Volume
docker run --rm -v app_data:/volume -v $(pwd):/backup busybox tar czf /backup/app_data.tar.gz /volume
This will create app_data.tar.gz in your current directory.
♻️ Restore a Volume
docker run --rm -v app_data:/restore -v $(pwd):/backup busybox tar xzf /backup/app_data.tar.gz -C /
🔐 Tip: Keep backups versioned and encrypted, especially for databases.
Step 7 — Automating with Docker Compose
Compose simplifies multi-container deployments, letting you define services, networks, and volumes in a single YAML file.
Example: Web + Database Stack
version: "3.8"
services:
web:
image: nginx
volumes:
- app_data:/usr/share/nginx/html
networks:
- backend
ports:
- "8080:80"
db:
image: postgres
environment:
POSTGRES_PASSWORD: example
volumes:
- db_data:/var/lib/postgresql/data
networks:
- backend
volumes:
app_data:
db_data:
networks:
backend:
Deploy the stack:
docker compose up -d
🧭 Result:
nginxandpostgrescontainers share the same network and persist their data in managed volumes.
Step 8 — Permissions, Security, and SELinux
File Permissions
Mounted directories must be writable by the container’s user.
Use chown and chmod if necessary:
sudo chown -R 1000:1000 ~/data
sudo chmod -R 755 ~/data
SELinux Considerations
If you are on an SELinux-enabled system (e.g., Fedora, CentOS), you might need to add context flags:
-v /host/path:/container/path:Z
The
:Zoption relabels files so that they are accessible by container processes.
Step 9 — Troubleshooting Common Issues
| Symptom | Possible Cause | Solution |
|---|---|---|
| Containers cannot communicate | Not on the same user-defined network | Use docker network connect |
| Volume not writable | Permission mismatch | Adjust ownership or use :Z for SELinux |
| Overlay network not reachable | Swarm not initialized | Run docker swarm init |
| Data lost after restart | Anonymous volume used | Define a named volume explicitly |
Step 10 — Real-World Use Case Example
Imagine a simple microservice stack:
frontend(React)backend(FastAPI)db(PostgreSQL)
Each runs in its own container, sharing a single overlay network and dedicated volumes.
Your Compose setup might look like this:
version: "3.9"
services:
frontend:
image: react-app
networks: [app_net]
ports: ["3000:3000"]
backend:
image: fastapi-app
networks: [app_net]
volumes:
- logs:/app/logs
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: securepass
volumes:
- pgdata:/var/lib/postgresql/data
networks: [app_net]
networks:
app_net:
driver: overlay
attachable: true
volumes:
logs:
pgdata:
This layout scales horizontally — additional nodes can join the Swarm and attach to app_net seamlessly.
Conclusion
In this guide, you learned how to:
- Create and manage Docker networks (
bridge,host,overlay) - Understand inter-container communication
- Persist data using named volumes and bind mounts
- Automate configuration using Docker Compose
- Back up and restore your volume data safely
With these fundamentals, you can now confidently design and deploy containerized environments with reliable networking and durable storage — both on your local machine and across distributed Swarm clusters.
Next Steps
- Learn about Docker Swarm services and load balancing
- Explore Traefik or Nginx Reverse Proxy integration
- Add Prometheus + Grafana to monitor network and disk I/O metrics
- Practice building multi-node stacks using overlay networks
(Admin Metadata Suggestion)
- Slug:
docker-networking-volumes-setup - Category:
Docker & Container Technologies - Keywords:
docker network, bridge, overlay, bind mount, volume backup, swarm, compose, persistent storage - Summary: “Learn how to configure Docker networks and volumes, automate them with Compose, and back up persistent data for real-world environments.”