Docker hat sich zum Standard gemausert, wenn es um das Verteilen von Diensten und Programmen geht: Im Fahrwasser der Cloud gilt es heute als sehr elegant, wenn der Anbieter einer Lösung anstelle der üblichen Pakete für RHEL & Co. ein Docker-Image ausliefert. Das geht besonders gut, weil Docker auf allen Zielsystemen dieselbe Umgebung garantiert: Läuft der Docker-Container also beim Autor, läuft er auch beim Anwender und lässt sich sogar entsprechend vorkonfigurieren.
Dass Docker-Container wie eine bessere Alternative zu den Paketverwaltungen der gängigen Distributionen – also RPM und Dpkg – scheinen, kann jedoch über eine Tatsache nicht hinwegtäuschen: Die Design-Annahmen, die Docker und den per Docker verteilten Containern zugrunde liegen, unterscheiden sich von der klassischen Virtualisierung fundamental. Ein großer Unterschied ist, dass ein Docker-Container ab Werk keinen persistenten Speicher hat: Löscht der Admin einen Container, sind alle darin enthaltenen Daten verloren.
Zum Glück bietet Docker für das Problem eine Lösung an: Per Volume-Dienst lässt sich ein Container mit persistentem Speicher versorgen. Der Volume-Dienst ist dabei lediglich eine API, die auf Funktionen in den geladenen Docker-Plug-ins zurückgreift. Für viele Arten von Speicher existieren mittlerweile solche Plug-ins, die die direkte Anbindung von Containern an eine bestimmte Speichertechnik ermöglichen. Dieser Artikel erklärt zunächst, wie persistenter Speicher in Docker grundsätzlich gedacht ist und warum der Umweg über den Volume-Dienst nötig ist. Danach zeigen wir am Beispiel zweier Umgebungsarten, OpenStack und VMware, wie sich mittels des passenden Plug-ins persistenter Speicher in Docker verwenden lässt.
Dass bei einem Docker-Container persistenter Speicher nicht automatisch zum Lieferumfang jedes Containers gehört, hat seinen Grund
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.