Backup und Recovery von Docker-Containern

Wer ein Image langfristig sichern möchte, muss die Ausgabe von »docker save« in eine beliebige Datei umleiten. Die Endung "TAR" ist dabei insofern vorgesehen, als dass das Docker-Werkzeug sowohl beim Sichern als auch beim Laden von Images auf das Archivformat setzt. Zum eigentlichen Image gelangen Sie dann folgendermaßen:

$ docker save docker/whalesay > cowsay.tar

$ ls -sh cowsay.tar

247M cowsay.tar

Damit haben Sie eine Datei zur Verfügung, die Sie nach Belieben in einer Cloud oder anderswo speichern können. Vor der Langzeitarchivierung empfiehlt sich die Kompression mit 7z oder einem ähnlichen Kompressionstool, da Tar in Reinform keine Kompression anwendet und sich nur auf das Entfernen des "Paddings" zwischen den Dateien beschränkt.

Zum Zurückspielen bietet sich das Gegenstück von »docker save« an: »docker load« . Im Fall unseres Images sähe der Aufruf folgendermaßen aus:

$ docker load --input cowsay.tar

Nach Abarbeitung des Befehls liegt das Image im lokalen Imagecache der Runtime und steht zum Anlegen neuer Container bereit.

Aus technischer Sicht spricht übrigens nichts dagegen, die zurückgelieferten Images entweder in einen lokalen oder in den "globalen" Hub zu verschieben. Der Vorteil dieser Vorgehensweise ist die einfachere Bereitstellung, die ohne manuelles Bewegen der Dateien auskommt. Als Nachteil haben Sie allerdings den zusätzlichen Aufwand mit der Verwaltung des Repositories.

Zustandslos bedeutet sicher

Der beste Weg zum Erreichen von Ausfallsicherheit ist Fehlertoleranz. Aufgaben lassen sich beispielsweise in kleine Task-Pakete verteilen, schnell startende und auch ebenso schnell wieder herunterfahrende Container bearbeiten ihre Work-loads dann dynamisch. In diesem Fall müssen Sie sich um die Gesundheit der "Worker" keine Gedanken machen, da sie im Fall eines technischen Problems einfach neu starten und die Arbeit fortsetzen. Zustandslose Designs sind für diese Art Aufgabe naturgemäß am besten geeignet. Anstatt die Container überwachen zu müssen, kümmern Sie sich im Idealfall nur um Orchestrierung und Datenbank. Alles andere darf nach Lust und Laune niedergehen und wiederauferstehen.

Doch zeigt die praktische Erfahrung, dass viele Aufgaben nicht oder nur sehr leidlich über zustandslose Systeme realisierbar sind. Wenn Sie Informationen vorhalten müssen, steht in der Docker-Welt eine Vielzahl von Methoden zur Verfügung. Von der Idee her am einfachsten – in der Praxis oft aber am schwierigsten zu realisieren – ist die Verwendung eines außerhalb des Verbunds stehenden Speichers (siehe Bild 2). Liegen alle für die Docker-Verarbeitung relevanten Informationen auf einem SQL-Server oder einem ähnlichen Speichersystem, müssen Sie sich um Docker-spezifische Belange keine Sorgen machen. Sichern Sie die Daten in diesem Fall auf die gewohnte, von Datenbankhersteller vorgegebene Art und Weise.

Die Idee, innerhalb des Docker-Containers neben der eigentlichen Payload auch einen Backup-Prozess auszuführen, schlägt in dieselbe Kerbe. Bietet der Anbieter der eigentlichen Nutzlast einen automatischen Sicherungsdienst an, sollten Sie dieses Angebot nutzen. Benötigen Sie unbedingt "lokalen" Speicherplatz, stellt Docker sowohl bind mounts als auch die in Bild 3 schematisch vorgestellten Volumes zur Verfügung.

Die Nutzung von Volumes ist in mehrerlei Hinsicht vorteilhaft. Die eigentliche Realisierung der Datenzugriffsschicht erfolgt über vom Entwickler bereitzustellende Treiber. Neben dem im Docker enthaltenen primitiven Treibern gibt es Kandidaten, die das Teilen eines Volumen mit mehreren Containern erlauben – eine Gruppe von Arbeitern greift so auf einen gemeinsamen Job-Pool zu. Weitere Informationen hierzu finden sich beispielsweise unter [1]. Das Absichern der Payloads ist der nächste Akt.

Bild 1: Die Befehle docker save und load arbeiten mit Standardeingabe und Standardausgabe. Fehlt eine Umleitung, geben sie eine Fehlermeldung aus und stellen den Betrieb ein.

Wiederherstellen von Containern

Insbesondere die kommerziellen Versionen von VMware, VirtualBox und Co. halten virtuelle Maschinen auf Zuruf an, um sie später fortzusetzen. In vielen Fällen lassen sich die Images auf eine andere Maschine oder einen anderen Server übertragen, um ihre Arbeit dort fortzusetzen. Diese Vorgehensweise ist für die Clientsoftware im Allgemeinen transparent und sorgt nicht für Probleme. Manche Programme sind ausgenommen – geht ein Algorithmus beispielsweise davon aus, dass sich die Systemzeit linear verändert, so bekommt er bei einem größeren Sprung Probleme. Docker-Container bieten seit einiger Zeit ein ähnliches Feature an. Zur Demonstration der Möglichkeiten wollen wir im ersten Schritt einen Container anwerfen. Im Interesse der Bequemlichkeit greifen wir auf den Standard-Ubuntu-Container zurück:

$ docker run -it ubuntu /bin/bash

root@7c8c8f9daca7:/#

Da Ubuntu von Haus aus keinen Editor mitliefert, wollen wir uns damit zufriedengeben, im Stammverzeichnis des root-Benutzers eine neue Datei anzulegen:

root@7c8c8f9daca7:/# ls

bin countup.sh

Da unser soeben angelegter Container ohne Volume und andere persistente Speicher auskommt, müsste die Datei bei einem Neustart verschwinden. Dies ist ein valider Weg zu überprüfen, ob der Container das Einschlafen und Aufwachen unbeschadet überlebt hat.

Bild 2: Befindet sich die Datenbank außerhalb von Docker, ist die Sicherung einfacher.