Begriff
Docker Volume
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Container sind vergesslich. Wenn sie sterben, löscht Docker ihre Festplatte.
Docker Volumes sind das Gedächtnis.
Ein Volume ist ein spezieller Ordner, der außerhalb des Containers sicher verwahrt wird.
Der Container darf ihn benutzen ("mounten"), aber er gehört Docker.
Wenn du den Container löschst, bleibt das Volume da.
Du kannst es später einem neuen Container geben ("Hier sind deine alten Erinnerungen").
Im Gegensatz zu Bind Mounts (Pfad auf deinem Desktop) liegen Volumes in einem von Docker verwalteten Bereich (/var/lib/docker/volumes) und sind daher robuster und portabler.
Merksatz: Ein von Docker verwaltetes Dateisystemobjekt zur persistenten Datenspeicherung, das unabhängig vom Lebenszyklus eines Containers existiert und von mehreren Containern genutzt werden kann.
- Erstellen:
docker volume create mein-daten-topf. - Nutzen:
docker run -v mein-daten-topf:/app/data nginx. - Inspect:
docker volume inspect mein-daten-topf. (Zeigt den echten Pfad auf der Linux-Platte). - Löschen:
docker volume rm mein-daten-topf. (Geht nur, wenn kein Container es mehr benutzt!). - Aufräumen:
docker volume prune(Löscht alle ungenutzten Volumes. Vorsicht!).
Praxisroutine
In der Praxis lernst du Docker Volume, indem du mit einem kleinen, kontrollierten Beispiel beginnst. Baue zuerst einen Minimalfall, prüfe das Ergebnis, veraendere genau eine Sache und beobachte, was sich ändert. Notiere dir Eingabe, Aktion, Ausgabe und typischen Fehler.
Übung: Erstelle ein Beispiel aus deinem Alltag, fuehre den Ablauf gedanklich Schritt für Schritt durch und markiere die Stelle, an der du Feedback oder ein Log brauchst. Wenn du diese Stelle benennen kannst, verstehst du den Begriff praktisch.
1. Volume Plugins (REX-Ray, Portworx)
Der Standard-Treiber (local) speichert auf der lokalen Festplatte.
Das ist doof im Cluster (Swarm/K8s). Wenn der Container auf Server B umzieht, sind seine Daten noch auf Server A.
Volume Plugins lösen das.
Der Container sagt: "Ich brauche Volume X".
Das Plugin sagt: "Moment, ich hänge die AWS EBS Disk an Server B an und mounte sie."
Das ermöglicht "Stateful Microservices".
2. Copy-on-Write Verhalten
Wenn du ein leeres Volume in /usr/share/nginx/html mountest, kopiert Docker den Inhalt aus dem Image (die index.html) in das Volume.
Das ist super praktisch ("Populate Volume").
Wenn du aber einen Bind Mount nimmst, verdeckt ("overshadow") er den Ordner. Er ist leer. Nginx zeigt "403 Forbidden".
Das ist der häufigste Anfängerfehler beim Wechsel von Volume zu Bind Mount.
3. Backups
Wie sichere ich ein Volume?
Du kommst auf Mac/Windows nicht an /var/lib/docker/volumes ran (liegt in der VM).
Der offizielle Weg:
docker run --rm -v mein-volume:/data -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /data
Starte einen Hilfs-Container, mounte das Volume UND einen lokalen Ordner, und zippe die Daten rüber.
Die Trennung von Base-Image und Volume
Man darf Storage / Graph Drivers (Overlay2, btrfs) nicht mit Volume Drivers (local, NFS, cloud) verwechseln.
Alle Änderungen, die ein Container ohne Volumes vornimmt (z. B. apt install oder Datei-Upload in /tmp), landen im "Container Layer" (verwaltet vom Storage Driver via Copy-on-Write).
Diese CoW-Architektur ist für Leseoperationen rasant, aber beim Schreiben extrem CPU- und I/O-hungrig, da Dateien vor der Manipulation erst aus unteren layern hochkopiert (Read-Modify-Write) werden müssen.
Dokumentierte Best Practice: Schreibintensive Anwendungen (PostgreSQL, Elasticsearch) müssen zwingend in ein Volume schreiben. Ein Volume umgeht den Storage Driver des Daemons völlig und schreibt direkt nativ auf das Host-Dateisystem, wodurch der Storage-I/O-Overhead entfällt und native NVMe/SSD Speeds ermöglicht werden.
NFS Volumes & UID Mapping Hell
Wenn Cluster (Swarm) Daten teilen müssen, ist "Local" tot. Oft rufen Teams NFS-Volumes ("Network File System") auf den Plan, z. B. NetApp Filer oder AWS EFS.
Du generierst Volumes durch Mount-Flags direkt: --opt type=nfs --opt o=addr=192.168.1.1,rw --opt device=:/path/to/dir.
Das massive Problem dabei ist Permission-Squashing / UID Mapping. Ein Alpine-Container greift als User root (UID 0) auf das NFS-Laufwerk zu. Der NFS-Server verbietet aus Sicherheit UID-0-Zugriffe (root_squash) und ändert den Besitzer auf nobody (meist UID 65534). Die Datenbank im Container verliert augenblicklich das Schreibrecht und stirbt mit "Permission Denied", was oftmals tagelanges Linux-Rechte-Debugging auslöst.
Volume Backup & Recovery Strategies (Immutable Data)
Volume Backups bedienen per Definition "Out-of-Band" Abläufe.
Da Docker keine Snapshot-APIs mitliefert (anders als VMware oder AWS für EBS), nutzen Admins "Tarballing" via Sidecar Container (z.B. den Officiellen Trick über docker run --rm --volumes-from <cid>).
In Produktion, insbesondere für Datenbanken, ist simples "Wegkopieren" fatal.
Eine Backup-Lösung darf niemals ein Volume per VFS komprimieren, während der Daemon aktiv Datenbank-Transactions dorthin flusht. Das Resultat ist "Torn Pages" (korrupte Blöcke). Der korrekte Life-Cycle lautet: Container stoppen oder Read-Only locken (z. B. Redis BGSAVE triggern), Datei kopieren/tar-en, und danach Unlocken. Bei distributed Storage-Backends übernimmt dies ein CSI Snapshot in Kubernetes.
Quick-Check
Sind Volumes schneller als Bind Mounts?
Auf Linux nativ: Nein (beides gleich). Auf Mac/Windows: JA! Bind Mounts müssen durch das langsame osxfs/VirtioFS Dateisystem. Volumes liegen komplett in der Linux-VM und sind rasend schnell (Native Speed).Kann ich ein Volume mit 2 Containern gleichzeitig nutzen?
Ja. Beide können lesen und schreiben. Aber Vorsicht vor "Race Conditions" (Wer schreibt zuletzt?). Docker sperrt nichts. Die App muss das regeln.Dangling Volumes?
Volumes, die kein Container mehr nutzt. Sie fressen oft GB an Platz. Docker löscht sie nie automatisch (außer beiprune), weil "User Data is precious".