Docker Networking & Volumes: Setup and First Steps

24 October 2025
Özet: This comprehensive guide explains how Docker networking and volume configurations work. You will learn about bridge, host, and overlay network modes, the differences between bind mount and named volume, and how to automate everything with Docker Compose. Real-world examples, data persisten

Docker Networking & Volumes: Setup and First Steps

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 mounts and named 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 with sudo privileges but not as root.
Use sudo where 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:
nginx and postgres containers 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 :Z option 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.”
Makale Sayfasına Dön