Docker Volumes and Storage

🐳 Docker Volumes and Storage: Your Container’s Memory Box

The Story of Disappearing Data

Imagine you have a beautiful sandcastle on the beach. You spend hours making it perfect. Then the waves come… and it’s gone! 😢

Containers are like sandcastles. When they stop, everything inside disappears!

But wait—what if you could keep your sandcastle safe in a magic box that the waves can’t touch? That’s exactly what Docker Volumes do!

🎒 What Are Docker Volumes?

Think of a volume as a special backpack that Docker gives you.

• Your container is like a student going to school
• The backpack (volume) holds important stuff
• Even if the student changes classes (container restarts), the backpack stays safe!

graph TD
    A["🐳 Container"] -->|Uses| B["📦 Volume"]
    B -->|Stores| C["💾 Your Data"]
    A -->|Stops| D["Container Gone"]
    B -->|Still exists!| C

Key insight: Volumes live OUTSIDE containers. That’s why data survives!

📦 Named Volumes: Your Data’s VIP Locker

A named volume is like having your own locker at school with your name on it.

Why Use Named Volumes?

• Docker manages everything for you
• Easy to find: just remember the name!
• Super safe—Docker protects it

Creating a Named Volume

docker volume create my-data

That’s it! You just created a locker called my-data.

Using a Named Volume

docker run -v my-data:/app/data nginx

What this means:

• my-data = your locker name
• /app/data = where it appears inside the container
• nginx = the container using it

Real Example: Database That Remembers

# Create volume for database
docker volume create db-storage

# Run database with volume
docker run -d \
  -v db-storage:/var/lib/mysql \
  mysql:8

Now your database remembers everything, even after restarts!

🔗 Bind Mounts: Your Computer Shares with Docker

A bind mount is like sharing your homework folder with a friend.

When to Use Bind Mounts?

• Development: See code changes instantly
• Config files: Use files from your computer
• Logs: Access container logs directly

Bind Mount Syntax

docker run -v /my/local/path:/container/path nginx

The key difference: Bind mounts start with / (a real path on your computer).

Real Example: Development Setup

docker run -d \
  -v $(pwd)/src:/app/src \
  -v $(pwd)/config.json:/app/config.json \
  node:18

What happens:

• Your src folder → container’s /app/src
• Edit files locally → changes appear instantly in container!

🛠️ Creating Volumes

Method 1: Explicit Creation

# Basic creation
docker volume create awesome-data

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

Method 2: Auto-Creation (Docker Does It)

# Docker creates volume if it doesn't exist
docker run -v new-volume:/data nginx

Magic! If new-volume doesn’t exist, Docker creates it automatically.

Method 3: Docker Compose

version: '3.8'
services:
  database:
    image: postgres:15
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:  # Volume declared here

📊 Managing Volumes

List All Volumes

docker volume ls

Output looks like:

DRIVER    VOLUME NAME
local     db-storage
local     my-data
local     app-cache

Remove a Volume

# Remove specific volume
docker volume rm my-data

# Remove only if not in use
# (This is the default - Docker protects you!)

Remove Unused Volumes (Cleanup!)

# Remove all orphan volumes
docker volume prune

# Force without confirmation
docker volume prune -f

Warning: This deletes ALL volumes not used by containers!

Remove Volume with Container

# Remove container AND its volumes
docker rm -v my-container

🔍 Volume Inspection

Want to peek inside a volume? Here’s how!

Basic Inspection

docker volume inspect my-data

Output tells you everything:

[
  {
    "Name": "my-data",
    "Driver": "local",
    "Mountpoint": "/var/lib/docker/volumes/my-data/_data",
    "Labels": {},
    "Scope": "local"
  }
]

Key Information:

• Name: The volume’s identity
• Mountpoint: Where data actually lives on host
• Driver: How Docker stores it (usually local)

Check Volume Size

# See disk usage
du -sh /var/lib/docker/volumes/my-data/_data

Find Which Container Uses a Volume

docker ps -a --filter volume=my-data

🔄 Data Persistence Patterns

Pattern 1: Database Persistence

The Problem: Databases need to remember data!

docker run -d \
  --name my-postgres \
  -v pgdata:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=secret \
  postgres:15

Result: Stop, restart, remove container—data survives!

Pattern 2: Shared Data Between Containers

The Problem: Two containers need the same files.

# Container 1: Writes data
docker run -d -v shared:/data writer-app

# Container 2: Reads data
docker run -d -v shared:/data reader-app

graph LR
    A["Writer Container"] -->|Writes| V["📦 shared volume"]
    V -->|Reads| B["Reader Container"]

Pattern 3: Development with Hot Reload

docker run -d \
  -v $(pwd):/app \
  -v /app/node_modules \
  node:18

Trick: The anonymous volume /app/node_modules prevents overwriting installed packages!

Pattern 4: Configuration Files

docker run -d \
  -v ./nginx.conf:/etc/nginx/nginx.conf:ro \
  nginx

The :ro means read-only—container can’t change your config!

💾 Volume Backup and Restore

Backup: Save Your Data

Think of this as making a copy of your locker contents!

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

What happens:

1. Temporary container starts
2. Mounts your volume as /source (read-only)
3. Creates tar.gz backup in current directory
4. Container removes itself (--rm)

Simple Backup Script

#!/bin/bash
VOLUME_NAME="my-data"
BACKUP_DIR="./backups"
DATE=$(date +%Y%m%d_%H%M%S)

docker run --rm \
  -v ${VOLUME_NAME}:/source:ro \
  -v ${BACKUP_DIR}:/backup \
  alpine \
  tar czf /backup/${VOLUME_NAME}_${DATE}.tar.gz -C /source .

echo "Backup created: ${VOLUME_NAME}_${DATE}.tar.gz"

Restore: Bring Data Back

docker run --rm \
  -v my-data:/target \
  -v $(pwd):/backup:ro \
  alpine \
  sh -c "cd /target && tar xzf /backup/my-backup.tar.gz"

What happens:

1. Temporary container starts
2. Mounts destination volume as /target
3. Extracts backup into volume
4. Container removes itself

Copy Between Volumes

docker run --rm \
  -v source-vol:/from:ro \
  -v dest-vol:/to \
  alpine \
  sh -c "cp -a /from/. /to/"

🎯 Quick Decision Guide

graph TD
    A["Need to store data?"] -->|Yes| B{What kind?}
    B -->|Database/App data| C["Named Volume"]
    B -->|Code/Config| D["Bind Mount"]
    B -->|Temporary| E["No volume needed"]
    C --> F["docker volume create"]
    D --> G["Use full path"]

🌟 Remember These Golden Rules

1. Containers are temporary, volumes are permanent
2. Named volumes = Docker manages it for you
3. Bind mounts = Your files, shared with Docker
4. Always backup important volumes!
5. Use :ro for read-only protection

🎉 You Did It!

You now understand Docker volumes like a pro! Your data will never disappear like a sandcastle in the waves again.

What you learned:

• Named volumes for managed storage
• Bind mounts for local file sharing
• Creating and managing volumes
• Inspecting volume details
• Persistence patterns for real apps
• Backup and restore strategies

Go forth and containerize with confidence! 🐳✨