Ja, das ist aus einigen Perspektiven ganz anders. Wie Sie im Titel der Frage geschrieben haben, geht es darum zu verstehen, warum wir Datenmengen benötigen, anstatt Mount an Host zu binden.
Teil 1 - Grundlegende Szenarien mit Beispielen
Nehmen wir zwei Szenarien.
Fall 1: Webserver.
Wir möchten unserem Webserver eine Konfigurationsdatei zur Verfügung stellen, die sich häufig ändert.
Beispiel: Anzeigen von Ports gemäß der aktuellen Umgebung.
Wir können das Image jedes Mal mit dem entsprechenden Setup neu erstellen oder 2 verschiedene Images für jede Umgebung erstellen. Beide Lösungen sind nicht sehr effizient.
Mit Bind Mounts stellt Docker das angegebene Quellverzeichnis an einem Ort im Container bereit.
(Das ursprüngliche Verzeichnis / die ursprüngliche Datei in der schreibgeschützten Ebene im Union-Dateisystem wird einfach überschrieben.)
Beispiel: Binden eines dynamischen Ports an nginx:
version: "3.7"
services:
web:
image: nginx:alpine
volumes:
- type: bind #<-----Notice the type
source: ./mysite.template
target: /etc/nginx/conf.d/mysite.template
ports:
- "9090:8080"
environment:
- PORT=8080
command: /bin/sh -c "envsubst < /etc/nginx/conf.d/mysite.template >
/etc/nginx/conf.d/default.conf && exec nginx -g 'daemon off;'"
(*) Beachten Sie, dass dieses Beispiel auch mit Volumes gelöst werden kann.
Fall 2: Datenbanken.
Docker-Container speichern keine persistenten Daten: Alle Daten, die in die beschreibbare Ebene im Union-Dateisystem des Containers geschrieben werden, gehen verloren, sobald der Container nicht mehr ausgeführt wird.
Aber was ist, wenn auf einem Container eine Datenbank ausgeführt wird und der Container stoppt - das bedeutet, dass alle Daten verloren gehen?
Bände zur Rettung.
Dies sind benannte Dateisystembäume, die von Docker für uns verwaltet werden.
Beispiel: Persistierende Postgres SQL-Daten:
services:
db:
image: postgres:latest
volumes:
- "dbdata:/var/lib/postgresql/data"
volumes:
- type: volume #<-----Notice the type
source: dbdata
target: /var/lib/postgresql/data
volumes:
dbdata:
Beachten Sie, dass in diesem Fall bei benannten Volumes die Quelle der Name des Volumes ist (bei anonymen Volumes wird dieses Feld weggelassen).
Teil 2 - Vergleich
Unterschiede in der Verwaltung und Isolation auf dem Host
Bindungs-Mounts sind im Host-Dateisystem vorhanden und werden vom Host-Betreuer verwaltet.
Anwendungen / Prozesse außerhalb von Docker können diese ebenfalls ändern.
Volumes können auch auf dem Host implementiert werden, Docker verwaltet sie jedoch für uns und kann außerhalb von Docker nicht aufgerufen werden.
Volumes sind eine viel umfassendere Lösung
Obwohl beide Lösungen uns helfen, den Datenlebenszyklus von Containern zu trennen, erhalten Sie durch die Verwendung von Volumes viel mehr Leistung und Flexibilität gegenüber Ihrem System.
Mit Volumes können wir unsere Daten effektiv entwerfen und von anderen Teilen des Systems entkoppeln, indem wir sie an bestimmten Remotestandorten (z. B. Cloud) speichern und in externe Dienste wie Backups, Überwachung, Verschlüsselung und Hardwareverwaltung integrieren.
