Matthias S. schrieb:
ich habe mir einen Rechner mit div. Docker-Containern zerschossen. Dabei
durfte ich feststellen, dass meine BackUp-Strategrie wohl nicht die
beste war. Die beruhte drauf mit Resiliosync das
Docker-Volume-Verzeichnis /var/lib/docker/volumes auf einen anderen
Rechner zu synchronisieren.
"Nicht die beste BackUp-Strategrie" ist eine feine Untertreibung. :-)
Einige Container konnte ich ganz gut wieder zu laufen bringen, in dem
ich nach dem zurück kopieren (mithilfe eines Docker-Containers) ein
'chmod -R 777 ./' über das Volume ausgeführt habe.
Auch ein "chmod -R 777" ist keine besonders gute Strategrie, aber das haben die Kollegen in diesem Thread Dir ja bereits gesagt... So etwas wie
1 |
find <dir> -type d -print0 | xargs -0 -- chmod 755
|
2 |
find <dir> -type f -print0 | xargs -0 -- chmod 644
|
ist immer meistens noch keine gute Strategrie, aber immerhin besser, als alles (!) mit Lese-, Schreib- und Ausführrechten (!) zu versehen.
Etwas kurios ist dagegen InfluxDB (1.8):
Daten des Volumes zurück kopiert, 'chmod -R 777 ./' darüber ausgeführt.
Und kein chown(1)? Hm.
Container läuft, Datenbanken sind da, Benutzer sind da, NodeRed kann
Daten reinschreiben, Grafana kann Daten auslesen. Aber: alle bisherigen
Daten sind irgendwie weg, bzw. Grafana zeigt diese nicht mehr an -
obwohl die ja eigentlich da drinnen stecken sollten?
Leider kenne ich mich mit InfluxDB nicht aus, dafür aber mit einigen anderen Datenmanagementsystemen. Manche davon haben SEHR eigenwillige Vorstellungen davon, wem ihre Dateien und Verzeichnisse zu gehören und welche Permissions sie gefälligst zu haben haben. Das hier (vom klugen Ernst, natürlich) schon genannte PostgreSQL etwa verweigert den Start, wenn sein Datenverzeichnis nicht dem Benutzer "postgres" gehört, oder nicht die Permissions 0700 oder 0750 hat. Das ist auch gut so, denn in den Daten eines Datenmanagementsystems hat außer ihm selbst natürlich grundsätzlich nichts etwas zu suchen.
Und dann, hach ja, die Benutzerkennungen oder, genauer, die User-IDs. Weil so ein Linux-Setup ein, sagen wir mal... schwer vorhersagbares Ding ist, werden Benutzerkennungen häufig dynamisch vergeben, auch für Daemon- und Systemuser. Mit on-the-fly gestarteten Docker-Containern läßt sich das leicht überprüfen: installiere ich dort zuerst InfluxDB und dann PostgreSQL, dann sehen die UID so aus:
1 |
username | uid
|
2 |
---------+-----
|
3 |
influxdb | 100
|
4 |
postgres | 102
|
Installiere ich hingegen zuerst PostgreSQL und dann InfluxDB, haben die User plötzlich ganz andere User-IDs:
1 |
username | uid
|
2 |
---------+-----
|
3 |
postgres | 101
|
4 |
influxdb | 102
|
(Vor PostgreSQL wird noch ein User "messagebus" angelegt, aber das spielt hier keine Rolle.)
Du siehst: die Benutzerkennungen, unter denen Deine Prozesse innerhalb Deiner Container laufen, sind nicht immer dieselben -- und, Achtung: auch nicht die auf Deinem Hostsystem. Das führt hier bei mir beispielsweise zu der lustigen Situation, daß die Datendateien meines OpenSearch-Containers im Container die User-ID 1000 des Benutzers "opensearch", aber auf dem Host die User-Id meines normalen Shellbenutzers haben. In meinem Redis-Container hat der Redis-Server die Benutzerkennung "redis" mit der User-ID 999, die auf meinem Host dem User "systemd-coredump" vorbehalten ist.
Also -- und das ist der Punkt -- in Deinen Docker-Volume-Verzeichnissen auf Deinem Host, also: jenen Verzeichnissen, die Du mit Deiner "Backup-Strategrie" herum kopierst, legen die Prozesse Deiner Containern ihre Daten unter jener User-ID ab, mit der die Prozesse in Deinen Containern laufen. Die muß nicht einmal mit Deinem Host konsistent sein, und ist es höchstwahrscheinlich auch nicht zwischen verschiedenen Docker-Containern (oder -Generationen).
Okay, wie gehen wir mit dem "Problem" jetzt um? Da gibt es verschiedene Ideen und Strategien, die erste ist ein Feature namens userns-remaß, also Sub-UIDs und Sub-GIDs, die Manpages dazu gibt es in subuid(5) und subgid(5). Damit lassen sich Unter-IDs für Systembenutzer einrichten, aber Achtung: Docker läuft entweder mit oder ohne, und wer dieses Feature einschaltet, muß wissen, daß seine existierenden Container dann nicht mehr starten. Siehe auch [1].
Dann gibt es die Möglichkeit, feste User-IDs in den Containern bereits beim Erzeugen der Images festzulegen, sei es mit useradd(8) oder adduser(8), oder (diese Möglichkeit ist eher unbekannt) indem einfach die passenden Dateien passwd und group in /etc des Image angelegt werden, /bevor/ die gewünschte Software installiert wird. Einfach ein
1 |
echo 'nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin' > /etc/passwd
|
2 |
echo 'nogroup:x:65534:' > /etc/group
|
im "RUN" eines Dockerfile und danach ein "USER nobody", schon läuft der ganze Prozess im Container als "nobody" mit der User-ID 65534. Ebenso kann man eine definierte User-ID beispielsweise für Benutzer wie "postgres" oder "influxdb" anlegen, bevor die betreffende Software im Image installiert wird -- oder wenn sie bereits installiert ist, mit usermod(8) die angelegten User modifizieren und ihnen fest vorgegebene User-IDs zuzuweisen (dann allerdings auch die bei der Installation angelegten Dateien und Verzeichnisse... genau). Die letztere Möglichkeit funktioniert sogar, ohne daß die Benutzerverwaltungswerkzeuge im Image installiert worden sind.
Wie dem auch sei: am Ende wirst Du für jede halbwegs zuverlässige Strategie reproduzierbare User- und Group-IDs brauchen.
[1] https://docs.docker.com/engine/security/userns-remap/
Bessere Idee für BackUps? Interessant wäre ja:
https://github.com/alaub81/backup_docker_scripts
Da ich über das BackUp dann auch noch ein versioniertes BackUp laufen
lasse (Duplicati), würde ich mir in dieses jede Menge große Volumes
reinspeichern, was auch irgendwie doof ist...
Was nützt Dir die beste Backup-Strategrie, wenn Du das Restore nicht getestet hast? Richtig: nichts, oder, anders gesagt: hast Du kein Backup. Und ohne Dir zu Nahe treten zu wollen: einfach nur Daten irgendwohin sichern kostet zwar Speicherplatz, bietet Dir aber keine Garantie, sie im Falle eines Desasters wiederherstellen zu können. Und Dir irgendwas un- oder halb Verstandenes aus dem Internet zusammen zu kopieren, macht die Sache kaum besser.
In meinem ganz persönlichen Fall sind die allermeisten Images selbst erzeugt, und haben ein eigenes Programm als ENTRYPOINT. Je nachdem, wie es aufgerufen wird, arbeitet es als reiner Entrypoint und nutzt den Systembefehl exece(2), um den "eigentlichen" Entrypoint des Image zu starten. Gleichzeitig fungiert es mit den passenden Argumenten aber auch als HEALTHCHECK und bei Containern, die Daten persistieren, werden diese in Tarballs auf STDOUT gedumpt oder aus ebensolchen von STDIN restauriert. Dadurch haben die Images eine einheitliche Bedienung, die sich obendrein über Labels prima automatisieren läßt. Das ist zwar ein bisschen Arbeit, aber sehr komfortabel. Und es verträgt sich prima mit meinen versionierten Backups (noch rsnapshot, künftig wohl Borg).
Wie dem auch sei: wenn Deine Datenmengen nicht exorbitant groß oder variant sind, dann ist es meist einfacher, Deine Daten mit "docker exec" erstmal in einen konsistenten Dump zu überführen und dann ins Backup zu schieben. Die meisten mir bekannten Backupwerkzeuge bieten die Option, vor dem Anfertigen eines neuen Backup ein oder mehrere Skripte auszuführen. Nutze sie.
