Docker Volumes vs Bind Mounts

Zwei Wege Daten zu persistieren. Beide haben ihre Berechtigung.

Der Unterschied

Bind Mount:

volumes:
  - ./data:/app/data

Verzeichnis vom Host wird in den Container gemountet.

Docker Volume:

volumes:
  - app_data:/app/data

volumes:
  app_data:

Docker verwaltet das Volume. Liegt unter /var/lib/docker/volumes/.

Wann Bind Mount?

1. Entwicklung mit Hot-Reload

services:
  app:
    volumes:
      - ./src:/app/src

Code-Änderungen direkt im Container sichtbar.

2. Konfigurationsdateien

volumes:
  - ./config/nginx.conf:/etc/nginx/nginx.conf:ro

Einfach zu editieren, versionierbar.

3. Einfacher Datei-Zugriff

volumes:
  - ./uploads:/app/uploads

Uploads direkt auf dem Host sichtbar. Backup = cp -r uploads/ backup/.

4. Logs

volumes:
  - ./logs:/app/logs

tail -f logs/app.log vom Host.

Wann Docker Volume?

1. Datenbanken

services:
  postgres:
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

Warum?

• Bessere Performance (kein Host-Filesystem-Overhead)
• Docker optimiert für Container-Workloads
• Funktioniert auf allen Plattformen gleich

2. Caches

volumes:
  - cache:/app/cache

Schnell, ephemeral, Docker verwaltet.

3. Daten die der User nicht sehen muss

Wenn kein direkter Dateizugriff nötig.

4. Multi-Container Sharing

services:
  app:
    volumes:
      - shared_data:/data

  worker:
    volumes:
      - shared_data:/data

volumes:
  shared_data:

Performance-Vergleich

Auf Linux kaum Unterschied. Auf macOS/Windows sind Volumes deutlich schneller.

Backup

Bind Mount

cp -r ./data backup/
# oder
tar -czf backup.tar.gz data/

Docker Volume

docker run --rm \
  -v db_data:/data \
  -v $(pwd):/backup \
  alpine tar -czf /backup/db_data.tar.gz /data

Oder mit Volume-Name:

docker volume inspect db_data --format '{{.Mountpoint}}'
# /var/lib/docker/volumes/db_data/_data

Meine Praxis

services:
  app:
    volumes:
      # Bind Mounts
      - ./config:/config:ro        # Konfiguration
      - ./uploads:/uploads         # User-Uploads
      - ./logs:/logs               # Logs

  db:
    volumes:
      # Docker Volume
      - db_data:/var/lib/postgresql/data

  redis:
    volumes:
      # Docker Volume
      - redis_data:/data

volumes:
  db_data:
  redis_data:

Tipps

Read-only wenn möglich

volumes:
  - ./config:/config:ro

Container kann nichts kaputt machen.

Named Volumes benennen

volumes:
  myapp_db_data:      # Gut
  data:               # Schlecht - zu generisch

Volumes aufräumen

# Ungenutzte Volumes löschen
docker volume prune

# Alle Volumes eines Projekts
docker compose down -v

Fazit

• Bind Mount: Dev, Config, Logs, direkter Zugriff nötig
• Docker Volume: Datenbanken, Caches, Performance kritisch

Beides hat seinen Platz. Richtig einsetzen!