Docker Restore Test auf Raspberry Pi
Diese Anleitung soll an einem praktischen Beispiel zeigen, wie man auf dem Raspberry Pi seine Docker Umgebung als Restore Test zum laufen bekommt. Das Backup der Umgebung, die ich wiederherstellen möchte basiert auf dem Artikel Docker Backup und Restore - eine kleine Anleitung und wurde mit den, in diesem Artikel verlinkten Backup Skripten, erstellt und in /backup abgespeichert.
- Docker Compose Project Backup Script
- Docker Volume Backup Script
- Docker MySQL and MariaDB Backup Script
Ich möchte nun die gesamte Umgebung auf dem Raspberry Pi wiederherstellen und Testen ob die Compose Projekte wieder funktionsfähig sind.
Zu beachten ist, das ich auf einem x86_64BIT System meine Live Umgebung laufen habe und der Raspberry Pi 3 im Standrad ein arm32v7 System ist. Deshalb werden nicht alle Images direkt lauffähig sein. Der Restore auf einem gleichen System verhält sich deutlich unproblematischer!
Vorbereitung
Als Vorbereitung sollte man diese Anleitung auf dem Raspberry Pi ausführen:
Nun holen wir uns alle Backup Dateien auf den Raspberry Pi. Wer möchte kann sich auch nur die neusten holen. Der Einfachheit halber hole ich mir das gesamte /backup Verzeichnis auf den Pi.
scp -r -P 22 root@servername.domain.tld:/backup /
Restore
Der Restore erfolgt nun händisch in der Konsole.
Docker Compose Projekt Restore
Als erstes entpacken wir die Docker-Compose Projekte nach /opt/COMPOSEPROJEKT. Dazu legen wir als ersten den Compose-Projekt Ordner an und entpacken dann das tar.gz in diesen Ordner:
mkdir /opt/COMPOSEPROJEKT
tar -xzvf /backup/compose/COMPOSEPROJEKT-TIMESTAMP.tar.gz -C /opt/COMPOSEPROJEKT/
zum Beispiel für den NGINX Proxy:
mkdir /opt/nginxproxy
tar -xzvf /backup/compose/nginxproxy-202002121020.tar.gz -C /opt/nginxproxy/
Nun starten wir das Compose-Projekt ganz einfach:
cd /opt/nginxproxy
docker-compose up -d
wir können teste ob das Projekt hochfährt in dem wir via netstat schauen ob die Ports 80 und 443 offen sind:
netstat -tulpn |grep -E -w '80 | 443'
die Ausgabe sollte so aussehen:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 28669/nginx: master tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 28669/nginx: master tcp6 0 0 :::80 :::* LISTEN 28669/nginx: master tcp6 0 0 :::443 :::* LISTEN 28669/nginx: master
Will man alle gesicherten Compose Projekte auf einmal zurückspielen, kann man sich das Leben ein wenig einfacher machen:
# zuerst das richtige Datum der Restore Dateien wählen,
# sollte im besten Fall das letzt Verfügbare Datum sein
# also den Timestamp (YYYYMMDD) setzen
TIMESTAMP=20200212
# dann ins Verzeichniss wechseln
cd /backup/compose
# Und dann alles entpacken (/opt/COMPOSEPROJEKT)
for i in $(ls *$TIMESTAMP*); do mkdir /opt/${i%%-*} && tar -xzvf $i -C /opt/${i%%-*}; done
nun sollten unter /opt alle Compose Projekte die im Backup Ordner waren zurückgesichert und bereit für den ersten Start sein:
for i in $(find /opt -iname "docker-compose.yml"); do cd ${i%/*} && docker-compose up -d ;done
Sollte es hierbei zu einer der folgenden Fehlermeldung kommen:
- 32bit Raspbian:
ERROR: no matching manifest for linux/arm/v7 in the manifest list entries
- 64bit Raspbian:
ERROR: no matching manifest for linux/arm/v8 in the manifest list entries
Dann gibt es für das verwendete Image keine ARM (arm32v7, armhf, arm64v8, aarch64) Unterstützung. Ich hatte das Problem beim MariaDB und beim MySQL Image. Hier kann man einfach auf ein ARM (arm32v7, armhf, arm64v8, aarch64) taugliches Image zurückgreifen. Ich nutze die Raspberry Pi OS 64Bit Version und habe für MariaDB dieses Image benutzt:
- linuxserver/mariadb:latest
Für MySQL gibt es wohl keine ARM Docker Images, weshalb man hier ebenfalls auf MariaDB umsteigen sollte.
Nach dem Ändern auf diese Images konnte ich die beiden Compose Projekte (Mediawiki und Wordpress) hochfahren.
Volume Daten Restore
Händisch geht das ganze in dem man einen Hilfscontainer nutzt, der A das Volume mountet in dem die Backup Dateien liegen und B das Docker Volume, in das wir die Dateien entpacken wollen. Bitte beim unterstehenden die folgenden Dinge anpassen:
- DOCKER-VOLUME-NAME
- BACKUPFILE.tar.gz
docker run --rm \
-v /backup/volumes:/backup \
-v DOCKER-VOLUME-NAME:/data \
debian:stretch-slim bash -c "cd /data && /bin/tar -xzvf /backup/BACKUPFILE.tar.gz"
Wenn ihr die oben stehenden Backup Scripte verwendet habt, könnt ihr auch hier wieder alles auf einen Schlag machen. Dafür einfach in den Volume Backup Ordner wechseln und die For Schleife kopieren und ausführen.
# zuerst das richtige Datum der Restore Dateien wählen,
# sollte im besten Fall das letzt Verfügbare Datum sein
# also den Timestamp (YYYYMMDD) setzen
TIMESTAMP=20200212
# dann ins Verzeichniss wechseln
cd /backup/volumes
# dann den restore anstoßen
for i in $(ls *$TIMESTAMP*); do
docker run --rm \
-v /backup/volumes:/backup \
-v ${i%%-[0-9]*}:/data \
debian:stretch-slim bash -c "cd /data && /bin/tar -xzvf /backup/$i"
done
Import der Datenbank Dumps
Die Datenbank Dumps spielt man am besten händisch ein. Im Normalfall hat man hier auch nicht allzuviel zu tun. Die Benötigten Variablen bekommt man einfach mit folgendem Befehl ausgeben:
docker exec CONTAINERNAME env
Wir benötigen das Root Passwort und den Datenbank Namen. Mit diesen Informationen kann man dann einfach den folgenden Befehl editieren und ausführen
zcat BACKUPFILE.sql.gz | docker exec -i CONTAINERNAME /usr/bin/mysql -u root --password=ROOTPASSWORD DATABASENAME
nun sollte die Datenbank mit dem SQL Backup gefüttert sein. Die Applikation steht nun zur Verfügung.
Test
Nachdem nun alle Backup Dateien eingespielt wurden, sollte man am besten alle Compose Projekte nochmals Neustarten:
for i in $(find /opt -iname "docker-compose.yml"); do cd ${i%/*} && docker-compose restart ;done
Dann mit dem folgenden Befehl schauen ob alle Container Up and Running sind:
docker ps -a
Sollten hier Container im Restarting Modus sein, dann sollte man diese prüfen und schauen wieso dies so ist. mit dem folgenden Befehl kann man sich die Logausgabe der Container anschauen:
docker logs CONTAINERNAME
Meist liegt es daran, das die Images nicht unter der ARM Umgebung lauffähig sind und durch andere Images ersetzt werden müssen. Bei mir gab es Probleme bei:
- Mysql --> ersetzt durch
linuxserver/mariadb:latest - MariaDB --> ersetzt durch
linuxserver/mariadb:latest - Certbot --> ersetzt durch
tobi312/rpi-certbot - Parsoid --> ersetzt durch ... Keine Lösung gefunden
Nun habe ich einfach in meinem MacOS die hosts Datei so umgebogen dass meine Domains auf die IP des Raspberry Pi zeigen und habe alle Applikationen durchgetestet. FERTIG :-)