Die Geschichte des Problems der Übertragung von Docker-Speicher (Docker-Root)

Vor ein paar Tagen wurde entschieden, den Docker-Speicher (das Verzeichnis, in dem Docker alle Dateien von Containern und Images speichert) auf eine separate Partition auszulagern, die
eine größere Kapazität hatte. Die Aufgabe schien trivial und ohne Komplikationen zu sein…

Fangen wir an:

1. Stoppen und beenden Sie alle Container unserer Anwendung:

docker-compose down

Wenn es viele Container gibt und sie in verschiedenen Compose-Dateien sind, kann man so vorgehen:

docker rm -f $(docker ps -q)

2. Stoppen Sie den Docker-Dienst:

systemctl stop docker

3. Verschieben Sie das Verzeichnis an den gewünschten Ort:

cp -r /var/lib/docker /docker/data/storage

4. Informieren Sie den Docker-Dienst, dass er im neuen Verzeichnis schauen soll. Hier gibt es mehrere Optionen: entweder mit dem Flag -g den Dienst auf den neuen Pfad verweisen oder über die Systemd-Konfigurationen, die wir verwendet haben. Oder ein Symlink. Ich werde da nicht ins Detail gehen, im Internet gibt es viele Anleitungen zum Verschieben des Docker-Root-Verzeichnisses an einen neuen Ort.

5. Starten Sie den Docker-Dienst und überprüfen Sie, ob er korrekt konfiguriert ist:

systemctl status docker

In einer der Ausgabelinien sollten wir sehen:

├─19493 /usr/bin/dockerd --data-root=/docker/data/storage

Sie haben überprüft, dass der Dienst die Option erhalten hat, jetzt prüfen wir, ob er sie angewendet hat (Danke inkvizitor68sl)!

docker info | awk '/Root Dir/ {print $NF}' 

6. Starten Sie unsere Anwendung:

docker-compose up -d

7. Überprüfen Sie

Und hier wird es spannend: DB, MQ, alles gut! Die Datenbank ist intakt, alles funktioniert... außer nginx. Wir haben eine eigene nginx-Version mit Kerberos und anderen Anpassungen. Beim Durchsehen der Container-Logs stellte sich heraus, dass er nicht in /var/tmp schreiben kann – Permission denied. Ich massiere meine Schläfen und versuche die Situation zu analysieren... Wie kann das sein? Das Docker-Image hat sich schließlich nicht geändert. Wir haben nur das Verzeichnis verschoben. Es hat immer funktioniert und jetzt das... Zum Experiment habe ich mich manuell in den Container begeben und die Rechte für dieses Verzeichnis geändert, es war root, root 755, ich gab root, root 777. Und alles funktionierte... In meinem Kopf kam der Gedanke – das ist doch verrückt... Ich dachte, vielleicht habe ich etwas übersehen...

Ich entschloss mich, dass wir die Datei-Berechtigungen beim Verschieben verloren haben. Wir stoppten die Anwendung, den Docker-Daemon, löschten das neue Verzeichnis und kopierten das Verzeichnis /var/lib/docker erneut mit rsync -a.

. Ich denke, jetzt sollte alles gut sein, wir starten Docker und die Anwendung.

Hmm... das Problem besteht weiterhin... Mein Auge zuckt. Ich bin zur Konsole meiner virtuellen Maschine gehastet, wo ich verschiedene Tests durchführe. Ich hatte dieses nginx-Image und bin in den Container eingestiegen. Dort in dem Verzeichnis /var/tmp sind die Berechtigungen auf root, root 777 eingestellt. Also genau die, die ich manuell festlegen musste. Aber die Images sind identisch!

Überall wurde das Dateisystem xfs verwendet.

Ich habe es mit dem Befehl verglichen

docker inspect my-nginx:12345

Alle Hashes sind identisch, alles eins zu eins. Sowohl auf dem Server als auch auf meiner virtuellen Maschine. Ich habe das lokale nginx-Image gelöscht und es neu aus dem Registry heruntergeladen, die aus verschiedenen Gründen auf demselben Rechner läuft. Und das Problem bleibt bestehen... Jetzt zuckt mein anderes Auge.

Ich kann mich nicht mehr erinnern, welche Gedanken mir durch den Kopf gingen, außer den Schreien "AAAHHHHH" und dem ganzen anderen Kram. Es ist 4 Uhr nachts draußen, und ich habe die Docker-Quellcodes durchforstet, um das Prinzip der Schicht-Hashierung zu verstehen. Ich habe die dritte Dose Energydrink geöffnet. Und schließlich ist mir klar geworden, dass die Hashierung nur die Datei und ihren Inhalt berücksichtigt, aber NICHT DIE BERECHTIGUNGEN! Das heißt, auf mysteriöse Weise wurden unsere Berechtigungen durcheinandergebracht, obwohl selinux deaktiviert ist, acl nicht verwendet werden und kein Sticky Bit gesetzt ist.

Ich habe das lokale Image gelöscht, ebenfalls das Image aus dem Docker-Registry entfernt und es neu hochgeladen. Und alles funktioniert jetzt. Anscheinend sind beim Übertragen die Berechtigungen sowohl im lokalen Image als auch im Image im Registry durcheinander geraten. Wie ich bereits erwähnt habe, befand es sich aus verschiedenen Gründen auf demselben Rechner. Und folglich in demselben Verzeichnis /var/lib/docker.

Und um die Frage vorwegzunehmen, ob wir versucht haben, Docker auf das alte Verzeichnis zurückzusetzen — nein, haben wir nicht, leider erlaubten die Umstände dies nicht. Zudem wollte ich die Sache wirklich klären.

Nachdem ich diesen Artikel geschrieben habe, erscheint mir die Lösung des Problems offensichtlich, aber zum Zeitpunkt der Analyse war das nicht der Fall. Ich habe ehrlich gegoogelt und keine ähnlichen Situationen gefunden.

Fazit: Problem gelöst, aber die Ursache habe ich immer noch nicht verstanden =(

Wenn jemand eine Ahnung oder Vermutungen über mögliche Ursachen dieses Problems hat — ich freue mich sehr über eure Kommentare!

Quelle: habr.com