Sie starten eine Datenbank in einem Container, fügen einige Daten hinzu, entfernen den Container und starten einen neuen. Die Daten sind weg. Fast jeder lernt diese Lektion auf die harte Tour. Docker-Volumes und Bind-Mounts dienen dazu, Daten über die Lebensdauer eines Containers hinaus am Leben zu halten.

In diesem Leitfaden wird erklärt, wie die einzelnen Funktionen funktionieren und wie man sie auswählt. Die Befehle und Dateien hier sind Standardbeispiele, die auf dem dokumentierten Verhalten von Docker basieren, und wir haben sie für diesen Artikel nicht ausgeführt, also probieren Sie sie zuerst mit Wegwerfdaten aus. Details können zwischen Docker-Versionen und auf Docker Desktop unterschiedlich sein. Wenn Sie neu im Umgang mit Containern sind, beginnen Sie mit unserem Docker-Tutorial für Anfänger.

Warum Containerdaten verschwinden

Ein Docker-Image besteht aus schreibgeschützten Ebenen. Wenn ein Container gestartet wird, fügt Docker oben eine dünne beschreibbare Ebene hinzu und alle Änderungen werden dort gespeichert. Diese Ebene übersteht einen Stopp und Neustart, wird jedoch entfernt, wenn der Container gelöscht wird.

docker run -d --name db -e POSTGRES_PASSWORD=devonly postgres:17
# ... create tables and add data ...
docker rm -f db
docker run -d --name db -e POSTGRES_PASSWORD=devonly postgres:17
# The data you added is not there

Dies ist beabsichtigt, da Sie so Behälter frei austauschen können. Das bedeutet allerdings, dass alles, was Sie aufbewahren müssen, außerhalb des Behälters aufbewahrt werden muss. Dafür gibt es drei Möglichkeiten:

Docker-Volumes vs. Bind-Mounts nebeneinander

Benannte Bände

Ein Volume ist ein von Docker erstellter und verwalteter Speicher. Sie nennen es namentlich und müssen sich nicht darum kümmern, wo es physisch lebt.

docker volume create pgdata

docker run -d --name db \
  -e POSTGRES_PASSWORD=devonly \
  -v pgdata:/var/lib/postgresql/data \
  postgres:17

Jetzt befinden sich die Datenbankdateien in pgdata. Löschen Sie den Container und starten Sie einen neuen mit demselben Volumen. Ihre Daten sind dann weiterhin vorhanden. Unter Linux liegen Volumes normalerweise unter /var/lib/docker/volumes/, Sie sollten diese Dateien jedoch nicht direkt bearbeiten. Auf Docker Desktop befinden sie sich in einer virtuellen Maschine, nicht in einem normalen Ordner.

Der Pfad innerhalb des Containers hängt vom Bild ab. Überprüfen Sie daher die Dokumentation des Bildes. Das Mounten auf den falschen Pfad ist ein klassischer Fehler: Alles scheint zu funktionieren, aber die Daten werden immer noch in die Containerschicht geschrieben. Auch neuere Hauptversionen eines Images können diesen Pfad ändern. Lesen Sie daher vor dem Upgrade die Versionshinweise.

Docker erstellt automatisch ein benanntes Volume, wenn es nicht existiert. Ein anonymes Volume, das ohne Namen erstellt wird, funktioniert ebenfalls, erhält aber eine lange zufällige ID und kann leicht den Überblick verlieren. Geben Sie Ihren Bänden immer Namen.

Reittiere binden

Ein Bind-Mount ordnet einen bestimmten Hostpfad direkt dem Container zu. Beide Seiten sehen sofort die gleichen Dateien. Dies macht es perfekt für die Entwicklung, da Änderungen in Ihrem Editor im laufenden Container wirksam werden, ohne dass ein Neuaufbau erforderlich ist:

docker run -d --name web \
  -p 8080:80 \
  -v "$(pwd)/site:/usr/share/nginx/html:ro" \
  nginx:1.27

Bearbeiten Sie eine Datei in site/, aktualisieren Sie den Browser und Sie werden die Änderung sehen. Durch :ro ist der Mount innerhalb des Containers schreibgeschützt, was eine gute Angewohnheit ist, wenn der Container dort nicht schreiben muss.

Bind-Reittiere bringen einige Kompromisse mit sich:

• Sie binden Sie an den Host. Der Pfad muss auf jedem Computer vorhanden sein, sodass Setups weniger portierbar sind.
• Sie verbergen den Inhalt des Bildes. Wenn Sie über /app montieren, wird alles, was sich im Bild befand, unsichtbar. Ein häufiges Beispiel ist das Verschwinden von node_modules.
• Sie machen den Host verfügbar. Ein Container mit einem beschreibbaren Mount kann echte Hostdateien ändern oder löschen. Mounten Sie niemals sensible Pfade wie / oder den Docker-Socket, es sei denn, Sie verstehen das Risiko vollständig.
• Die Leistung kann variieren. Auf Docker Desktop für macOS und Windows überschreitet die Dateifreigabe eine Virtualisierungsgrenze und kann langsamer sein als unter Linux.

tmpfs wird bereitgestellt

Ein tmpfs-Mount befindet sich im Speicher des Hosts und wird niemals in die Containerschicht geschrieben. Es verschwindet, wenn der Container stoppt, und eignet sich daher für temporäre Dateien, Caches und kurzlebige sensible Daten:

docker run -d --tmpfs /app/cache:size=64m myapp:1.0

tmpfs ist auf Linux-Hosts verfügbar. Es kann auch Datenbanken in wegwerfbaren Testumgebungen beschleunigen, in denen Sie sich nicht um die Aufbewahrung der Daten kümmern.

-v oder –mount?

Beide Flags funktionieren. --mount ist länger, aber expliziter, und viele Leute bevorzugen es in Skripten:

# Short form
docker run -v pgdata:/var/lib/postgresql/data postgres:17

# Explicit form
docker run --mount type=volume,source=pgdata,target=/var/lib/postgresql/data postgres:17

# Bind mount, read-only
docker run --mount type=bind,source="$(pwd)"/site,target=/usr/share/nginx/html,readonly nginx:1.27

Es gibt einen bedeutsamen Unterschied. Mit -v wird ein fehlender Hostpfad als leerer Ordner für Sie erstellt, der einen Tippfehler verbergen kann. Bei --mount und einem Bind-Typ meldet Docker stattdessen einen Fehler. Auch bei -v entscheidet die linke Seite über den Typ: Ein Name bedeutet ein Volume und ein Pfad bedeutet ein Bind-Mount. -v data:/x und -v ./data:/x machen also sehr unterschiedliche Dinge.

Volumes in Docker Compose

Die meisten realen Projekte deklarieren die Speicherung in einer Compose-Datei. Hier werden beide Arten verwendet, jede für ihre jeweilige Aufgabe:

services:
  web:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - ./src:/app/src      # bind mount: live code
    depends_on:
      - db

  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: devonly
    volumes:
      - pgdata:/var/lib/postgresql/data   # named volume: data

volumes:
  pgdata:

Benannte Volumes müssen im Abschnitt volumes der obersten Ebene deklariert werden. Compose stellt dem tatsächlichen Namen den Projektnamen voran. Eine vollständige Anleitung finden Sie in unserem Docker Compose-Tutorial.

Nützliche Lautstärkebefehle

Überprüfen Sie, was prune entfernt, bevor Sie es bestätigen, da dies nicht rückgängig gemacht werden kann. Volumes, die derzeit kein Container nutzt, können dennoch wichtige Daten enthalten.

Ein Volume sichern und wiederherstellen

Ein Volume kann gesichert werden, indem ein kurzlebiger Container ausgeführt wird, der sowohl das Volume als auch einen Hostordner bereitstellt:

# Back up
docker run --rm \
  -v pgdata:/data:ro \
  -v "$(pwd)":/backup \
  alpine tar czf /backup/pgdata.tar.gz -C /data .

# Restore into a new volume
docker volume create pgdata_restored
docker run --rm \
  -v pgdata_restored:/data \
  -v "$(pwd)":/backup \
  alpine tar xzf /backup/pgdata.tar.gz -C /data

Bei einer Live-Datenbank kann das Kopieren solcher Dateien zu einem inkonsistenten Zustand führen. Stoppen Sie zuerst den Container oder verwenden Sie besser das datenbankeigene Tool, z. B. pg_dump für PostgreSQL. Und ein Backup, das Sie nie wiederhergestellt haben, ist eigentlich nur eine Hoffnung, also testen Sie die Wiederherstellung.

Dateiberechtigungen

„Berechtigung verweigert“ ist das häufigste Problem bei Mounts. Unter Linux behalten Dateien ihre numerischen Benutzer- und Gruppen-IDs. Wenn also ein Container als Benutzer 1000 ausgeführt wird und der Hostordner einem anderen Benutzer gehört, schlagen Schreibvorgänge fehl. Einige Möglichkeiten, dies zu beheben:

• Führen Sie den Container mit einem passenden Benutzer aus: docker run --user "$(id -u):$(id -g)" ...
• Richten Sie den korrekten Besitz für Ihr Image ein, wie in unseren Dockerfile-Best Practices beschrieben.
• Bevorzugen Sie benannte Volumes für Daten, da ein neues Volume bei der ersten Verwendung den Besitz des Image-Ordners übernimmt.
• Auf Systemen, die SELinux verwenden, benötigen Bind-Mounts möglicherweise die Bezeichnung :z oder :Z.

Vermeiden Sie die Versuchung von chmod 777, wie unser Leitfaden zu Linux-Befehlen erklärt.

Welches sollten Sie verwenden?

Die letzte Reihe ist wichtig. In der Produktion gehört der Code in das Image, sodass Sie auch das ausführen, was Sie getestet haben. In Clustern funktioniert die Datenspeicherung wiederum anders, und zwar über persistente Volumes, die in der umfassenderen Kubernetes-Dokumentation behandelt werden. Unser Leitfaden Docker vs. Kubernetes erklärt, wie die beiden zusammenhängen.

Häufige Fehler

• Bereitstellung auf dem falschen Pfad. Die Daten befinden sich immer noch in der Containerschicht und verschwinden später.
• Wird down -v beiläufig ausgeführt. Dadurch werden Ihre benannten Volumes gelöscht.
• Verwendung relativer Pfade mit -v. Formulare wie -v data:/x erstellen ein Volume statt einer Ordnerzuordnung.
• Geheimnisse in beschreibbare Bind-Mounts einfügen. Hängen Sie sie schreibgeschützt ein oder verwenden Sie eine Geheimnisfunktion.
• Zwei Datenbankcontainer auf ein Volume verweisen. Dies kann die Daten beschädigen.
• Keine Backups vorhanden. Ein Volume ist kein Backup. Es lebt auf derselben Festplatte.

Fazit

Die Faustregel ist kurz: benannte Volumes für Daten, Bind-Mounts für Code, den Sie bearbeiten, und tmpfs für Dinge, die nicht von Dauer sein sollten. Versuchen Sie es mit einer Wegwerfdatenbank. Erstellen Sie ein benanntes Volume, fügen Sie eine Zeile hinzu, löschen Sie den Container, starten Sie einen neuen und bestätigen Sie, dass Ihre Zeile erhalten geblieben ist. Üben Sie dann ein Backup und eine Wiederherstellung, bevor Sie eines benötigen.

Häufige Fragen

Lerne weiter