Wie funktioniert Datenpersistenz mit Docker-Volumes?

Question

Accepted Answer

Standardmäßig sind Daten in einem Container **ephemär** — sie gehen verloren, wenn der Container entfernt wird. **Volumes** (und Bind Mounts) bieten **persistenten Speicher**, der Container überlebt und ist unverzichtbar für Datenbanken und alle Daten, die Container-Neustarts/Entfernungen überstehen müssen.

## Das Problem: Container sind ephemär

```text
A container's writable layer is DELETED when the container is removed:
  → data written inside the container (e.g. a database's files) is LOST
  → containers are meant to be disposable/replaceable → don't store important data in them
→ For persistent data, you need storage OUTSIDE the container's lifecycle.
```

## Volumes — verwalteter persistenter Speicher

```bash
# create and use a named volume (managed by Docker)
docker volume create mydata
docker run -v mydata:/var/lib/mysql mysql      # mount the volume into the container
# → data in /var/lib/mysql persists in the volume, surviving container removal

docker volume ls                 # list volumes
docker volume inspect mydata     # details
```

**Volumes** sind von Docker verwalteter persistenter Speicher (auf dem Host gespeichert, von Docker verwaltet) — der bevorzugte Weg, Daten zu persistieren. Daten im gemounteten Pfad bleiben erhalten, selbst wenn der Container entfernt wird.

## Bind Mounts — ein Hostverzeichnis mappen

```bash
# bind mount: map a specific HOST directory into the container
docker run -v /host/path:/app -p 3000:3000 myapp
docker run -v $(pwd):/app myapp   # mount the current directory (great for development)
# → changes on the host are reflected in the container (and vice versa)
```

**Bind Mounts** mappen ein Hostverzeichnis in den Container — nützlich für die Entwicklung (Code auf dem Host bearbeiten, Änderungen live im Container sehen).

## Volumes vs. Bind Mounts

```text
VOLUMES      → Docker-managed, portable, the preferred choice for PERSISTENT DATA
               (databases, uploads) — decoupled from the host's filesystem layout
BIND MOUNTS  → map a specific host path; great for DEVELOPMENT (live code reload)
               and sharing host files; tied to the host's filesystem
tmpfs        → in-memory (non-persistent), for sensitive/temporary data
```

## Warum es wichtig ist

Das Verständnis der Datenpersistenz mit Volumes ist wesentlich für die korrekte Verwendung von Docker mit jeder Anwendung, die Daten hat, daher ist es wichtiges praktisches Wissen.

Das grundlegende Problem — **Container sind ephemär**, ihre beschreibbare Schicht wird bei Entfernung gelöscht, das bedeutet, dass **Daten, die in einem Container geschrieben werden, verloren gehen** — ist ein kritisches Konzept: Container sollen austauschbar sein, daher führt das Speichern wichtiger Daten darin (wie Datenbankdateien) zu Datenverlust, wenn der Container ersetzt wird. **Volumes** lösen dies, indem sie **Docker-verwalteten persistenten Speicher** bereitstellen, der außerhalb des Container-Lebenszyklus existiert, sodass Daten (Datenbanken, Uploads, jeglicher Zustand) die Container-Entfernung und -Ersetzung überstehen — unverzichtbar für zustandsbehaftete Anwendungen.

Das Verständnis von **Bind Mounts** (ein Hostverzeichnis in den Container mappen) ist wichtig für die **Entwicklung** (Code auf dem Host bearbeiten und Änderungen live im Container sehen, ein sehr häufiger Entwicklungs-Workflow) und zum Teilen von Hostdateien.

Die **Unterscheidung** zu kennen — Volumes (Docker-verwaltet, portabel, die bevorzugte Wahl für persistente Anwendungsdaten wie Datenbanken) versus Bind Mounts (Host-Pfad-spezifisch, großartig für Entwicklung) — hilft bei der Wahl des richtigen Ansatzes.

Da Container konzeptionell ephemär sind und die meisten echten Anwendungen Daten haben, die persistieren müssen (besonders Datenbanken), und da Volumes der unverzichtbare Mechanismus für persistenten Speicher sind (mit Bind Mounts wichtig für Entwicklung), ist das Verständnis der Docker-Datenpersistenz — das ephemäre-Container-Problem, Volumes für persistente Daten, Bind Mounts für Entwicklung und wann jeweils verwendet — unverzichtbares, praktisch relevantes Docker-Wissen, notwendig für die korrekte Ausführung zustandsbehafteter Anwendungen und zum Vermeiden des ernsthaften Fehlers, Daten zu verlieren, die in austauschbaren Containern gespeichert sind.