Docker Restore Test auf Raspberry Pi

Aus Laub-Home.de Wiki
Zur Navigation springen Zur Suche springen

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.

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:

  1. 32bit Raspbian:

ERROR: no matching manifest for linux/arm/v7 in the manifest list entries

  1. 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 den 64Bit Kernel 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 :-)

Quellen