Docker Bind Mounts: Eine Übersicht

Docker Bind Mounts: Eine Übersicht

Container sind flüchtig. Alle Modifikationen, die ein Container an seinem Image vornimmt, verschwinden nach dem Löschen des Containers und sind auch nicht für andere Container sichtbar. Um Daten eines Containers zu persistieren und unabhängig von dessen Lebzeit zu machen, bietet Docker zwei Mechanismen: Volumes und Bind Mounts.

Verwendung von Bind Mounts

Ein einfacher und performanter Weg, Daten von einem Container abzukoppeln, sind Bind Mounts. Dabei wird ein Verzeichnis oder eine Datei auf dem Host-System an den Container gemountet. Ein passendes Szenario für einen solchen Mount wäre beispielsweise die PHP-Entwicklung in einem Container:

Bash:

$ docker container run -d -p 80:80 --name app -v $(pwd)/html-data:/var/www/html php:7.3-apache

Hier wird ein Container auf Basis des offziellen PHP-Images php:7.3-apache ausgeführt, das Apache als Webserver verwendet. Der Document-Root des Webservers ist /var/www/html. Um nicht bei jeder Änderung im Quellcode das Image neu bauen und dabei den neuen Quellcode ins Image-Dateisystem kopieren zu müssen, ist es sinnvoll, den Quellcode vom Container abzukoppeln - hier mit einem Bind Mount.

Dieser Bind Mount wird wahlweise mit -v oder mit --mount spezifiziert, worauf ich gleich eingehen werde. Wichtig ist hier, dass unser lokales Verzeichnis html-data, in dem der PHP-Quelltext liegt, in den Container an der Stelle /var/www/html eingehängt wird. Die Syntax ist also immer -v <Quelle am Host>:<Ziel im Container>. Ändert sich nun eine Datei im lokalen Verzeichnis, ist diese Änderung auch automatisch für den Container sichtbar. Der Webserver liefert dementsprechend immer den aktuellen Stand einer Datei aus.

Wichtig: Die Pfade müssen als absolute Pfade angegeben werden. Das erreiche ich unter Linux mit /pfad/zum/verzeichnis und unter Windows bei Docker Desktop beispielsweise mit /c/pfad/zum/verzeichnis. Ist das Quellverzeichnis auf dem Host noch nicht vorhanden, wird es automatisch erstellt.

Bessere Lesbarkeit mit --mount

Die oben verwendete -v-Option bietet tatsächlich noch einen dritten "Parameter", um Optionen für den Bind Mount angeben zu können. Beispielsweise ließe sich unser Projekt-Verzeichnis mit -v $(pwd)/html-data:/var/www/html:ro als read-only Mount in den Container einhängen.

Diese Schreibweise kann durchaus unübersichtlich werden. Aus diesem Grund wurde in Docker 17.06 die --mount-Option mit besser lesbarer Syntax auch für Standalone-Container eingeführt. Sie besteht aus mehreren Key-Value-Paaren, was die einzelnen Parameter selbsterklärender macht.

Bash:

$ docker container run -d \
  -p 80:80 \
  --name app \
  --mount type=bind,source=$(pwd)/html-data,destination=/var/www/html \
  php:7.3-apache

Ja, diese Schreibweise ist länger, sie erhöht aber auch die Lesbarkeit, die Reihenfolge der Argumente spielt keine Rolle mehr und die Flexibilität ist ebenfalls höher, worauf ich im nächsten Abschnitt eingehe. Im Gegensatz zur -v-Option muss das Quellverzeichnis auf dem Host bereits vorhanden sein.

Mit dem folgenden Befehl lässt sich der Mount an den Beispiel-Container verifizieren:

Bash:

$ docker container inspect -f "{{.Mounts}}" app

Mehr Möglichkeiten mit --mount

Neben den genannten Vorteilen ist die --mount-Option auch mächtiger als die Variante mit -v. Unter anderem können mit der Option nicht nur Bind Mounts, sondern auch andere Mounting-Mechanismen wie Volumes spezifiert werden. Hier eine kleine Übersicht der gültigen Key-Value-Paare:

type: Bestimmt den Typ des Mounts. In unserem Beispiel ist das natürlich bind, aber auch volume und tmpfs sind gültige Typen.
source: Kann auch als src angegeben werden und bestimmt das Quellverzeichnis auf dem Host.
readonly: Hat kein Value, sondern muss nur gesetzt sein. Gibt dem Container ausschließlich lesenden Zugriff auf das Host-Verzeichnis.
Plattform-spezifische Parameter: bind-propagation unter Linux und consistency für macOS. Braucht der normale Anwender überlicherweise nicht, weshalb ich sie hier auslasse.

Die Nachteile

Bind Mounts sind nur ein bestimmter Weg, Daten von einem Container zu entkoppeln. Für Anwendungsfälle, bei denen der Entwickler Dateien in einem Arbeitsverzeichnis ständig ändert, sind Bind Mounts eine gute Wahl. Leider aber sind Bind Mounts abhängig von der Verzeichnisstruktur auf dem Host-System, was die Portabilität (und damit eines der Hauptargumente für Docker) einschränkt. Zudem haben unter Umständen mehrere Nutzer und Prozesse Zugriff auf das Host-Verzeichnis, was ungewollte und vermeidbare Nebeneffekte haben kann.

Daher wurde eine Alternative zu Bind Mounts eingeführt, die für sämtliche andere Anwendungsfälle zu bevorzugen ist: Volumes.

Reaktionen: Werner S, JR Cologne und Mat

Docker Bind Mounts: Eine Übersicht

Weitere Ressourcen von dominik

Teilen