zhu difeng - Fotolia
Docker: Nutzen Sie Optionen für persistenten Speicher
In diesem Tutorial zeigen wir Ihnen, wie Sie für Docker Container persistenten Speicher einrichten und welche Vorteile dies im täglichen Einsatz bietet.
Docker hat sich seit zwei Jahren als eine flexible Alternative zur Virtualisierung für Web- und Cloud-Anwendungen etabliert. Dank ihrer autonomen Natur können Docker Container einfach ausgerollt werden, egal ob auf Cluster oder Server ohne Abhängigkeit von einem Host.
Ein Docker Container ist im Grundsatz ein Kapselungsmechanismus für Programmiercode und Prozesse einer Anwendung. Er täuscht dem Prozess die totale Kontrolle über den Host vor. Ein Docker Container ist eine Abart der Virtualisierung. Im Gegensatz zu klassischen virtuellen Maschinen (VM) teilen alle Container die Services und das zugrundeliegende Betriebssystem ihres Hosts.
Theoretisch ist die Isolierung der Container damit schwächer als die von VMs, weil sich die Container die Services des Knotens, Netzwerk- und Storage-Services des Host-Betriebssystems teilen. Aber das sorgt auch einen für erheblichen Vorteil, denn hunderte von Containern können auf einem einzigen Host ausgerollt werden.
Am Anfang dachte man nicht daran, dass Container auch persistenten Speicher benötigen könnten.
Wenn ein Docker Image ausgeführt wird, erschafft die Docker Engine ein temporäres Dateisystem, auf dem die Bestandteile und die erzeugten Daten abgelegt werden. Es nutzt dafür die Copy-on-Write-Funktionen des Union File Systems.
In der Praxis wird bei der Ausführung dieses Mechanismus (Copy-on-Write) dasselbe Image verschiedene Male auf denselben Host kopiert. Die Docker Engine macht dabei keine komplette Kopie, sondern führt die nötigen Modifikationen für jeden Container aus.
Dieser Mechanismus spart nicht nur Speicherplatz, sondern auch Zeit, vor allem beim Start des Containers. Ein Container kann binnen Sekundenbruchteilen gestartet werden.
Am Anfang waren Container vor allem für Microservices gedacht, wofür persistenter Speicher unnötig erschien. Das heißt aber, dass beim Beenden eines Containers auch die Daten verloren sind. Kein Problem für Microservices, aber andere Anwendungen haben stärkere Anforderungen. Und Docker wird in der Praxis zunehmend für anspruchsvolle Anwendungen eingesetzt.
Docker hat bereits eingebaute Funktionen für persistenten Speicher mitgebracht. Dazu gehören Volumen und DOCKER DATA VOLUME CONTAINERS. Es ist heute möglich, lokale Volumen für Docker auf SAN- oder NAS-Arrays einzurichten. Im Folgenden wollen wir dazu verschiedene Methoden beleuchten.
Docker Volume
Ein Docker Volume bietet eine Möglichkeit, das persistente Speichern eines Containers einzurichten oder Daten mit anderen Containern auf demselben Volumen auszutauschen.
Ein Docker Volume wird gestartet bei der Einrichtung eines Containers und wird dort gemountet wie ein Dateisystem. Wenn das Container Image bereits Daten und ein Dateisystem enthält, werden die Daten auf das neue Volumen bei der Initialisierung kopiert.
Das Volumen überlebt, wenn ein Container beendet wird. Docker löscht als Standardvorgabe keine Volumen, selbst wenn die zugehörigen Container getilgt werden. Tatsächlich ist es unmöglich, ein Volumen zu löschen, solange noch ein Container darauf verweist.
Ein Volumen kann mit folgendem Befehl angelegt werden:
docker volume create
Ebenso kann ein Volumen gestartet oder einem Container zugewiesen werden
docker create
oder
docker run command
Standardmäßig wird ein Volumen im Schreib-/Lese-Modus eingerichtet. Es ist aber auch möglich, es auf den Lese-Modus zu begrenzen. Der folgende Befehl richtet beispielsweise einen Container namens „Web“ auf dem Image „training/webapp“ und dem Volumen „/webapp“ auf einem lokalen Host ein:
$ docker run -d -P --name web -v /webapp training/webapp python app.py
Es gibt viele Optionen, um ein Volumen mit Daten zu versehen. Die erste besteht darin, ein Repository mit Betriebssystem als ein Data Volume zu hosten. Diese Option ist einfach umzusetzen, muss aber im Produktionsbetrieb vorsichtig angewandt werden, denn ein Ausfall des System-Hosts führt dazu, dass das Volumen nicht mehr verfügbar ist. Ein lokales Repository ist immer praktisch für Entwickler, egal ob bei der Development- oder der Testphase. Es sei darauf verwiesen, dass es auch möglich ist, einen einzelnen Datensatz als Volumen zu behandeln. Der folgende Befehl richtet beispielsweise einen Container namens „Web“ auf dem Image „training/webapp“ ein und mountet das Repository „/src/webapp“ auf dem Volumen „/webapp“ auf einem lokalen Host:
$ docker run -d -P --name web -v /src/webapp:/webapp training/webapp python app.py
Die zweite Möglichkeit ist es, ein verteiltes Storage-Volumen (iSCSI, Fibre Channel, NFS) als Datenvolumen zu mounten. Docker bringt ein Plug-in-Konzept mit, das es verschiedenen Storage-Herstellern erlaubt, ihre Arrays mit der Container-Technologie zu verbinden. Der Vorteil dieses Verfahrens besteht darin, dass das Volumen nicht fest mit einem Host verbunden ist, sondern für jeden Host im Cluster zugänglich ist. Das gilt dann, wenn die Hosts Zugang zu den Arrays haben und die Plug-ins installiert sind.
Der folgende Befehl mountet das Repository „/src/webapp“ auf dem Volumen „mein-volume:/webapp“ und nutzt den Volumentreiber „convoy“, der den NFS- und EBS-Zugang von Amazon unterstützt:
$ docker run -d -P \
--volume-driver=convoy \
-v mein-volume :/webapp \
--name web training/webapp python app.py
Data Volume Container
Docker bietet auch einen Mechanismus, um persistente Daten unter Containern zu verteilen. Dieser Mechanismus mit dem Namen Data Volume Container besteht darin, Container mit Volumen zu verbinden. Dadurch wird der Zugriff von Volumen auf andere Container ermöglicht.
Docker gibt dafür als Beispiel folgenden Befehl an, der einen Container namens „dbstore“ auf dem Image „training/postgres“ anlegt:
$ docker create -v /dbdata --name dbstore training/postgres /bin/true
Mit dem Parameter “-volume” aus „Docker run” wird es möglich, das Volumen „/dbdata“ des Containers „dbstore“ auf andere Container zu mounten.
Mit den beiden folgenden Befehlen werden die beiden Container „db1“ und „db2“ erzeugt:
$ docker run -d --volumes-from dbstore --name db1 training/postgres
$ docker run -d --volumes-from dbstore --name db2 training/postgres
Es sei darauf hingewiesen, dass das Abschalten der Container, auf denen die Volumen gemountet sind, nicht die Volumen selbst abschaltet. Um sich nicht mit verwaisten Volumen herumschlagen zu müssen, sollte man den Befehl
docker rm –v
auf den letzten Container anwenden, der auf das Volumen verweist.
Docker zeigt eine Liste verwaister Volumina mit dem folgenden Befehl an:
volume ls -f dangling=true
Unterdrückt werden unerwünschte Volumina mit dem Befehl:
volume rm <name_volume >
Außer dem Problem der verwaisten Volumina können bei der Verwendung von Data Containern noch weitere potentielle Gefahren lauern. Beispielsweise stellt Docker keine zusätzlichen Sicherheitsmechanismen bereit, um ein Volumen abzusichern. Man muss also die Zugriffsrechte der Nutzer von Containern im Auge behalten und sicherstellen, dass sie mit den Zugriffsrechten auf die Server-Hosts übereinstimmen. Docker bietet keinen zusätzlichen Sperrmechanismus. Wenn verschiedene Container auf dasselbe Volumen eines Hosts zugreifen, werden die Datensperren von den Anwendungen im Container gesetzt. Das könnte schließlich zur Korrumpierung von Daten führen. Bei einer verteilten Storage-Infrastruktur stellt sich dieses Problem nicht.
Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!
