Introduction: The Core of Container Communication and Data Management

Two of the most important topics in Docker application deployment are networking and volumes. In microservice architectures composed of multiple containers, inter-container communication is essential, and situations where data must persist even when containers are deleted are very common.

In this Part 5, we will deeply cover Docker's network model and volume system, with practical examples that can be applied in real production environments.

1. Docker Network Overview

1.1 The Need for Docker Networks

Containers run in isolated environments by default. However, in real applications, web servers need to communicate with databases, and API gateways need to connect with multiple microservices. Docker networks allow you to manage such inter-container communication safely and efficiently.

1.2 Basic Network Commands

# List networks
docker network ls

# View network details
docker network inspect [network-name]

# Create network
docker network create [network-name]

# Delete network
docker network rm [network-name]

# Delete all unused networks
docker network prune

2. Docker Network Types

2.1 Bridge Network (Default)

Bridge network is Docker's default network driver, allowing containers on the same host to communicate. When Docker is installed, a bridge network called docker0 is automatically created.

# Run container with default bridge network
docker run -d --name web1 nginx

# Check default bridge network info
docker network inspect bridge

Features:

  • Supports communication between containers on the same host
  • Uses NAT (Network Address Translation) between host and containers
  • External access allowed through port mapping (-p option)
  • Cannot communicate by container name on default bridge (IP only)

2.2 Host Network

Host network allows containers to use the host's network stack directly. Performance is good because there's no network isolation, but security caution is needed.

# Run container with host network
docker run -d --network host --name web-host nginx

# Directly accessible on host's port 80 without port mapping

Features:

  • Uses the same network environment as the host
  • Excellent network performance without NAT overhead
  • No port mapping needed (uses host ports directly)
  • Fully supported only on Linux (limited on macOS, Windows)

2.3 None Network

None network completely disables container networking. Used for batch jobs that don't need networking or security-critical environments.

# Run container with none network
docker run -d --network none --name isolated alpine sleep 3600

# Check network interfaces (only lo exists)
docker exec isolated ip addr

Features:

  • No network interface (only loopback exists)
  • Completely blocks external communication
  • Highest level of network isolation

2.4 Overlay Network

Overlay network enables communication between containers across multiple Docker hosts. It's essential in cluster environments like Docker Swarm or Kubernetes.

# Requires Swarm mode enabled
docker swarm init

# Create overlay network
docker network create -d overlay my-overlay-network

# Create service on overlay network
docker service create --name web --network my-overlay-network nginx

Features:

  • Supports container communication across multiple hosts
  • Virtual network using VXLAN technology
  • Automatic service discovery in Swarm mode
  • Built-in load balancing functionality

3. User-Defined Networks

3.1 User-Defined Bridge Network

Using a user-defined bridge network instead of the default bridge network provides several advantages.

# Create user-defined network
docker network create my-app-network

# Specify subnet and gateway
docker network create \
    --driver bridge \
    --subnet 172.20.0.0/16 \
    --gateway 172.20.0.1 \
    my-custom-network

# Connect containers to network
docker run -d --name db --network my-app-network mysql:8.0
docker run -d --name web --network my-app-network nginx

Advantages of user-defined networks:

  • Automatic DNS resolution: Communicate using container names
  • Better isolation: Automatically isolated from containers in other networks
  • Dynamic connection: Connect/disconnect running containers to networks
  • Configurable: Customize subnet, gateway, IP range, etc.

3.2 Communicating by Container Name

# Create user-defined network
docker network create app-net

# Run MySQL container
docker run -d \
    --name mysql-db \
    --network app-net \
    -e MYSQL_ROOT_PASSWORD=secret \
    mysql:8.0

# Web app can access using mysql-db as hostname
docker run -d \
    --name webapp \
    --network app-net \
    -e DB_HOST=mysql-db \
    my-webapp:latest

4. Inter-Container Communication

4.1 Communication Within Same Network

# Create network
docker network create backend

# Connect two containers to same network
docker run -d --name server1 --network backend alpine sleep 3600
docker run -d --name server2 --network backend alpine sleep 3600

# Ping test from server1 to server2
docker exec server1 ping -c 3 server2

4.2 Connecting to Multiple Networks

A single container can be connected to multiple networks. This is useful for containers serving as proxies or gateways.

# Create two networks
docker network create frontend
docker network create backend

# Database connected only to backend
docker run -d --name db --network backend mysql:8.0

# Web server connected to frontend
docker run -d --name web --network frontend nginx

# API server connected to both networks
docker run -d --name api --network frontend node:18
docker network connect backend api

4.3 Network Connect and Disconnect

# Connect running container to network
docker network connect my-network container-name

# Disconnect container from network
docker network disconnect my-network container-name

# Connect with specific IP address
docker network connect --ip 172.20.0.100 my-network container-name

5. DNS and Service Discovery

5.1 Built-in DNS Server

Docker provides a built-in DNS server (127.0.0.11) in user-defined networks. This allows discovering other containers by container name or network alias.

# Check DNS settings
docker exec webapp cat /etc/resolv.conf
# nameserver 127.0.0.11
# options ndots:0

5.2 Network Aliases

# Set network alias
docker run -d \
    --name mysql-primary \
    --network app-net \
    --network-alias db \
    --network-alias database \
    mysql:8.0

# Can access using db or database as name
docker run --rm --network app-net alpine ping -c 2 db

5.3 Round-Robin DNS

When multiple containers have the same network alias, Docker DNS returns IPs in round-robin fashion.

# Run multiple web servers with same alias
docker run -d --name web1 --network app-net --network-alias webserver nginx
docker run -d --name web2 --network app-net --network-alias webserver nginx
docker run -d --name web3 --network app-net --network-alias webserver nginx

# Requests to webserver connect to one of the three containers
docker run --rm --network app-net alpine nslookup webserver

6. The Importance of Data Persistence

6.1 Container Volatility

Containers are inherently ephemeral. When a container is deleted, all data stored inside the container is lost. This becomes a serious issue when dealing with important data like databases, user uploads, and configuration files.

# Create file inside container
docker run -d --name temp-container alpine sh -c "echo 'important data' > /data.txt && sleep 3600"
docker exec temp-container cat /data.txt  # important data

# Delete container
docker rm -f temp-container

# Data doesn't exist in new container
docker run --rm alpine cat /data.txt  # Error: file not found

6.2 When Data Persistence is Needed

  • Databases: Data files for MySQL, PostgreSQL, MongoDB, etc.
  • User uploads: Images, documents uploaded by users
  • Log files: Application logs, access logs
  • Configuration files: Application settings, certificates
  • Session data: Cache, session storage

7. Docker Volume Types

7.1 Volumes (Managed Volumes)

Docker-managed volumes are the most recommended approach. Volumes are created in Docker's storage area (/var/lib/docker/volumes/).

# Create volume
docker volume create my-data

# List volumes
docker volume ls

# Volume details
docker volume inspect my-data

# Run container with volume
docker run -d \
    --name db \
    -v my-data:/var/lib/mysql \
    mysql:8.0

# Or use --mount flag (more explicit)
docker run -d \
    --name db \
    --mount source=my-data,target=/var/lib/mysql \
    mysql:8.0

Advantages of Volumes:

  • Easy management with Docker CLI (backup, migration)
  • Works on both Linux and Windows containers
  • Can be safely shared between multiple containers
  • Supports remote storage and encryption via volume drivers
  • Independent of host filesystem structure

7.2 Bind Mounts

Mounts a specific host path to the container. Useful for real-time source code reflection in development environments.

# Mount host directory to container
docker run -d \
    --name web \
    -v /home/user/website:/usr/share/nginx/html \
    nginx

# Using --mount flag (more explicit)
docker run -d \
    --name web \
    --mount type=bind,source=/home/user/website,target=/usr/share/nginx/html \
    nginx

# Mount as read-only
docker run -d \
    --name web \
    -v /home/user/website:/usr/share/nginx/html:ro \
    nginx

Bind Mount Features:

  • Requires exact host path specification
  • Direct access to host filesystem
  • Suitable for real-time source code reflection in development
  • Auto-creates host directory if it doesn't exist (caution needed)

7.3 tmpfs Mounts

tmpfs stores data in host memory. Used for temporarily storing sensitive information or when high performance is needed.

# Use tmpfs mount
docker run -d \
    --name cache \
    --tmpfs /app/cache \
    my-app:latest

# Using --mount flag
docker run -d \
    --name secure-app \
    --mount type=tmpfs,destination=/run/secrets,tmpfs-size=64m \
    my-app:latest

tmpfs Features:

  • Very fast as stored only in memory
  • Data automatically deleted when container stops
  • Suitable for temporary storage of sensitive data (passwords, API keys)
  • Supported only on Linux

8. Volume Creation and Management

8.1 Creating and Viewing Volumes

# Create basic volume
docker volume create app-data

# Create volume with labels
docker volume create \
    --label project=myapp \
    --label env=production \
    myapp-data

# List all volumes
docker volume ls

# Filter by label
docker volume ls --filter label=project=myapp

# View specific volume details
docker volume inspect app-data

8.2 Deleting Volumes

# Delete specific volume (only if not in use)
docker volume rm app-data

# Delete all unused volumes
docker volume prune

# Delete with filter
docker volume prune --filter label=env=development

8.3 Sharing Volumes

# Create volume
docker volume create shared-data

# Use same volume from multiple containers
docker run -d --name writer -v shared-data:/data alpine sh -c "while true; do date >> /data/log.txt; sleep 5; done"
docker run -d --name reader -v shared-data:/data:ro alpine tail -f /data/log.txt

9. Volume Drivers

9.1 Local Driver Options

# Create NFS volume
docker volume create \
    --driver local \
    --opt type=nfs \
    --opt o=addr=192.168.1.100,rw \
    --opt device=:/path/to/share \
    nfs-volume

# Create volume with specific filesystem type
docker volume create \
    --driver local \
    --opt type=ext4 \
    --opt device=/dev/sdb1 \
    ext4-volume

9.2 Third-Party Volume Drivers

Various third-party volume drivers allow you to utilize cloud storage or distributed file systems.

  • Amazon EBS: AWS Elastic Block Store
  • Azure File Storage: Microsoft Azure file storage
  • GlusterFS: Distributed file system
  • Portworx: Enterprise container storage
  • REX-Ray: Supports various storage platforms

10. Data Backup and Restoration

10.1 Volume Backup

# Backup volume using temporary container
docker run --rm \
    -v my-data:/source:ro \
    -v $(pwd):/backup \
    alpine tar cvf /backup/my-data-backup.tar -C /source .

# Compressed backup
docker run --rm \
    -v my-data:/source:ro \
    -v $(pwd):/backup \
    alpine tar czvf /backup/my-data-backup.tar.gz -C /source .

10.2 Volume Restoration

# Create new volume
docker volume create my-data-restored

# Restore from backup
docker run --rm \
    -v my-data-restored:/target \
    -v $(pwd):/backup \
    alpine tar xvf /backup/my-data-backup.tar -C /target

10.3 Volume Replication Between Containers

# Copy from source volume to target volume
docker run --rm \
    -v source-volume:/source:ro \
    -v target-volume:/target \
    alpine cp -av /source/. /target/

10.4 Database Backup Examples

# MySQL database backup
docker exec mysql-container mysqldump -u root -p'password' --all-databases > backup.sql

# PostgreSQL database backup
docker exec postgres-container pg_dumpall -U postgres > backup.sql

# MongoDB database backup
docker exec mongo-container mongodump --archive --gzip > backup.gz

11. Practical Example: Web Application Stack

11.1 Complete Stack Using Networks and Volumes

# Create network
docker network create webapp-network

# Create volumes
docker volume create mysql-data
docker volume create webapp-uploads

# MySQL database
docker run -d \
    --name mysql \
    --network webapp-network \
    -v mysql-data:/var/lib/mysql \
    -e MYSQL_ROOT_PASSWORD=rootpass \
    -e MYSQL_DATABASE=webapp \
    -e MYSQL_USER=appuser \
    -e MYSQL_PASSWORD=apppass \
    mysql:8.0

# Web application
docker run -d \
    --name webapp \
    --network webapp-network \
    -v webapp-uploads:/app/uploads \
    -e DB_HOST=mysql \
    -e DB_USER=appuser \
    -e DB_PASSWORD=apppass \
    -e DB_NAME=webapp \
    -p 3000:3000 \
    my-webapp:latest

# Nginx reverse proxy
docker run -d \
    --name nginx \
    --network webapp-network \
    -v $(pwd)/nginx.conf:/etc/nginx/nginx.conf:ro \
    -p 80:80 \
    nginx:alpine

11.2 Managing with Docker Compose

# docker-compose.yml
version: '3.8'

services:
  mysql:
    image: mysql:8.0
    networks:
      - webapp-network
    volumes:
      - mysql-data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: webapp
      MYSQL_USER: appuser
      MYSQL_PASSWORD: apppass

  webapp:
    image: my-webapp:latest
    networks:
      - webapp-network
    volumes:
      - webapp-uploads:/app/uploads
    environment:
      DB_HOST: mysql
      DB_USER: appuser
      DB_PASSWORD: apppass
      DB_NAME: webapp
    depends_on:
      - mysql

  nginx:
    image: nginx:alpine
    networks:
      - webapp-network
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    ports:
      - "80:80"
    depends_on:
      - webapp

networks:
  webapp-network:
    driver: bridge

volumes:
  mysql-data:
  webapp-uploads:

12. Network and Volume Best Practices

12.1 Network Best Practices

  • Use user-defined networks: Use user-defined networks instead of default bridge for DNS resolution and isolation benefits
  • Expose only necessary ports: Minimize ports exposed externally with -p option
  • Separate networks by service: Separate frontend, backend, database into different networks
  • Utilize network aliases: Use aliases for flexible service discovery

12.2 Volume Best Practices

  • Use named volumes: Use named volumes instead of anonymous volumes for easier management
  • Bind mount for development, volume for production: Choose mount method appropriate for environment
  • Regular backups: Important data must be backed up regularly
  • Read-only mounts: Use :ro option for data that doesn't need modification like config files
  • Clean up unused volumes: Periodically clean up with docker volume prune

Conclusion

Docker networks and volumes are core components of container-based applications. Proper network configuration ensures safe and efficient communication between containers, and the right volume strategy secures data persistence and safety.

Summary of what we learned:

  • Docker network types (bridge, host, none, overlay) and their uses
  • Advantages of user-defined networks and DNS-based service discovery
  • Differences between volumes, bind mounts, and tmpfs with appropriate use scenarios
  • Data backup and restoration strategies

In Part 6, we will finally cover the basics of Kubernetes. We'll explore why Kubernetes is needed, how its architecture is structured, and what the core objects are.