Docker-Volumes-Tutorial​

loading="lazy" width="400px">Mit Docker-Volumes gehen Container und lokale File-Systeme gut zusammen.Robert Mandel | shutterstock.com Docker-Container sind unveränderlich (immutable). Der Code und die Daten, die sie enthalten, verändern sich also nie. Das ist nützlich, um sicher sein zu können, dass der Code, der in der Produktion zur Anwendung kommt, derselbe ist, der den Qualitätssicherungs-Check absolviert hat. Weniger nützlich ist Immutability hingegen, wenn Daten über Applikations-Lifetimes hinweg geschrieben und nachgehalten werden müssen. Zwar lässt sich das in den meisten Fällen durch eine externe Datenbank lösen. Manchmal braucht eine Container-Applikation jedoch nur ein lokales Dateisystem – oder etwas, das wie eines aussieht. An dieser Stelle kommen Docker-Volumes ins Spiel. Dabei handelt es sich um den nativen Mechanismus von Docker, um mit lokalem Storage umzugehen. Ein Docker-Volume ist eine bequeme Möglichkeit, um containerisierte Applikationen dazu zu befähigen, Daten über ein lokales Dateisystem oder eine Dateisystem-ähnliches Interface zu schreiben und abzurufen. Dabei sind Docker-Volumes aber kein Allheilmittel, um State zu managen. Vielmehr sind sie mit Bedacht einzusetzen. Warum, erfahren Sie in diesem Tutorial. Wie Docker-Volumes funktionieren Docker-Volumes eröffnen Entwicklern einen Weg, um einen Dateipfad – den sogenannten Mount Point – von innerhalb eines Containers auf einen Systempfad oder ein Datei-ähnliches Objekt außerhalb zu mappen. Sämtliche Inhalte, die in ein Docker-Volume geschrieben werden, werden extern gespeichert – bleiben also über die Lebensdauer eines oder mehrerer Container hinweg erhalten. Dabei ist es auch möglich, dass mehrere Container parallel auf dasselbe Volume zugreifen (mit einigen Einschränkungen). Um zu steuern, wo Daten gespeichert werden, nutzen Docker-Volumes einen Volume Driver. Zwei Beispiele: Blockbridge bietet über die Volume-Treiber-Ebene direkten Zugriff auf iSCSI-Ziele. Die Storage Engine REX-Ray ist mit einer Vielzahl von Anbietern und Standards kompatibel und bietet Konnektivität über das Volume-Plug-in-System von Docker oder die allgemeinere Container-Storage-Interface-Spezifikation. Docker-Volumes manuell erstellen Der simpelste Weg, ein Docker Volume zu erstellen: Wenn Sie einen Container aufsetzen, geben Sie das -v– oder -volume-Flag, den Mount Point und das Ziel an. $ docker run -P —name websvc -v /websvcdata myorg/websvc python app.py Damit erstellen Sie ein „anonymes“ Volume mit dem Mount Point websvcdata. Die Daten werden in einem zufällig generierten Verzeichnis gespeichert, das vom Docker-Prozess verwendet wird. Dasselbe Ziel erreichen Sie mit einem Dockerfile, indem Sie eine VOLUME-Anweisung einfügen, die den Speicherort des Volumes beschreibt: FROM ubuntu: latest VOLUME /websvcdata Das wäre eine gute Möglichkeit, um im Rahmen einer Container-Session eine „Quick and Dirty“-Datenablage zu schaffen. Um den State Container-Session-übergreifend beizubehalten, ist das allerdings keine gute Lösung, weil der Name des Volumes nicht vorab bekannt ist und es so nicht effizient wiederverwendet werden kann. Docker-Volume-API nutzen Eine bessere Lösung, um benannte Volumes zu erstellen, bietet die volume–API von Docker. Volumes dieser Art können einfach an einen oder mehrere Container angehängt und damit deutlich einfacher wiederverwendet werden. $ docker volume create websvcdata Dieser Code erzeugt ein Docker-Volume mit dem Namen websvcdata. Allerdings verfügt das Volume noch nicht über einen Mount Point innerhalb eines Containers. Ein Zugriff über Container ist deshalb standardmäßig nicht möglich. Um einen Mount Point zu erstellen, starten Sie den Container folgendermaßen: $ docker run -P —name websvc -v websvcdata:/websvcdata myorg/websvc python app.py Dieser Code ist weitgehend identisch zu dem ersten docker run-Beispiel. Mit dem Unterschied, dass das Volume nicht anonym, sondern mit dem Namen websvcdata auf dem Host erstellt wird. Um festzustellen, ob die Mounts Ihren Vorstellungen entsprechen, können Sie docker inspect auf dem Container ausführen und den Abschnitt "Mounts" im resultierenden Dump lesen. Zu beachten ist dabei, dass Sie kein benanntes Volume mit einem Dockerfile erstellen können, weil die Namen für die Volumes zur Laufzeit spezifiziert werden müssen. Das ist auch so gewollt, weil Dockerfiles nicht einfach davon „ausgehen“ können, dass ein bestimmter Host und seine Volume-Pfade existieren. Sie sind dazu gedacht, auf jedem System mit jedem Volume-Path-Set zu laufen. Ein Volume, das in einem Dockerfile spezifiziert wird, wird an einem Speicherort erstellt, der die Persistenz der enthaltenen Daten unterstützt. Indem Sie docker volume create mit spezifischen Flags für den Docker-Storage-Treiber ausführen, können Sie diverse Einstellungen beeinflussen, um ein Volume zu erstellen. Mit dem lokalen Dateisystemtreiber können Sie beispielsweise angeben, wo das Volume platziert werden soll und welches Gerät oder Dateisystem verwendet werden soll. Das ermöglicht, das Volume auf dem für den jeweiligen Anwendungsfall günstigsten Device zu platzieren. Tipp: Wenn Sie ein Volume erstellen und es mit einem Pfad innerhalb des Basis-Images verknüpfen, das bereits Daten enthält, werden die Daten innerhalb des Basis-Images zur Bind Time auf das Volume kopiert. Das ist eine praktische Möglichkeit, um ein Volume vorab mit Daten zu befüllen, die Sie als Ausgangspunkt verwenden möchten. Docker-Volumes zwischen Containern teilen Falls Sie mehr als einen Container an dasselbe Docker-Volume anhängen wollen, geht das ganz simpel: $ docker run -ti —name instance1 -v DataVol1:/datavol1 ubuntu $ docker run -ti —name instance2 —volumes-from DataVol1 ubuntu $ docker run -ti —name instance3 —volumes-from DataVol1:ro ubuntu Hierdurch werden drei Container erstellt (instance1 bis instance3) – und jedem davon DataVol1 angehängt. Der instance3-Container hat DataVol1 als schreibgeschützt gemountet – wie es :ro nach dem Volumennamen anzeigt. Zu beachten ist dabei, dass Docker Konflikte zwischen Containern, die sich dasselbe Volume teilen, nicht automatisch auflöst. Das ist Sache Ihrer Applikation (dazu gleich mehr). Docker-Volumes entfernen Volumes werden nicht automatisch von der Festplatte entfernt, sobald ein Container entfernt wird. Auch das ist beabsichtigt, schließlich wollen Sie kein Volume entfernen, das möglicherweise noch von einem anderen Container in der Zukunft verwendet werden könnte. Das hat zur Folge, dass Sie selbst für Unmounting- und Cleanup-Prozesse verantwortlich sind. Um den Volume-Cleanup zu erleichtern, bietet Docker jedoch integrierte Tools: Der Befehl docker volume verfügt über einen Sub-Befehl namens docker volume prune. Dieses Kommando entfernt sämtliche Datenträger, die nicht von mindestens einem Container im System verwendet werden. Den Umfang der Löschaktion können Sie übrigens auch konfigurieren und beispielsweise nur die Volumes entfernen, die einem bestimmten Container zugeordnet sind. Wo Docker-Volumes an ihre Grenzen kommen Docker-Volumes sind kein Allheilmittel für lokale Persistenz. Wegen der Art und Weise, wie Container mit lokalen Dateisystemen interagieren, können Docker-Volumes unter Umständen sogar mehr Probleme verursachen als lösen. Die wesentlichen Limitationen von Docker-Volumes im Überblick: Docker kümmert sich nicht um File Locking in Volumes, die von mehreren Containern genutzt werden. Das liegt in der Verantwortung der jeweils verwendeten Anwendung. Wenn die fragliche App nicht fähig ist, Daten in ein gemeinsam genutztes Dateisystem zu schreiben, droht File Corruption im Volume. Eine mögliche Lösung für das Problem wäre es, Object Storage Server statt eines lokalen Dateisystems zu verwenden – beispielsweise ein Projekt wie Minio. Docker-Volumes können zudem die Portabilität von Anwendungen erschweren: Jeder Rechner weist eine andere Speichertopologie auf. Wenn Sie Volumes auf der Grundlage von Annahmen darüber erstellen, wo sich Dinge im System befinden, kann es sein, dass diese Annahmen nicht zutreffen, wenn Sie versuchen, dieselben Container auf einem System einzusetzen, das Sie nicht selbst erstellt haben. Das ist weniger problematisch, wenn Sie Container nur auf Systemen verwenden, auf denen Sie die Topologie streng kontrollieren können, etwa auf einem internen privaten Cluster. Falls Sie sich später für eine neue Architektur entscheiden, holen die Problemen Sie jedoch wieder ein. Volumes zu nutzen, um Stateful Data zu speichern, ist nicht zu empfehlen. Diese sollten stattdessen über einen anderen nativen Docker-Mechanismus verarbeitet werden. Secrets in Applikationen sollten beispielsweise über die Docker-eigenen Systeme oder Drittanbieter-Produkte wie HashiCorp Vault gehändelt werden. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!