Die Geschichte des Problems der Migration des Docker-Speichers (Docker-Root)

Vor ein paar Tagen wurde beschlossen, den Docker-Speicher (Verzeichnis, in dem Docker alle Container- und Bilddateien speichert) auf eine separate Partition zu verschieben, die
eine größere Kapazität hatte. Die Aufgabe schien trivial und verhieß keine Probleme...

Loslegen:

1. Stoppen und töten 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-Daemon:

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-Daemon, dass er das neue Verzeichnis betrachten soll. Es gibt mehrere Optionen: Entweder durch den -g-Parameter den Daemon auf den neuen Pfad hinweisen oder die systemd-Konfigurationen verwenden, die wir verwendet haben. Oder einen symbolischen Link setzen. Ich werde das hier nicht im Detail darlegen; im Internet gibt es viele Handbücher zum Verschieben des Docker-Roots an einen neuen Ort.

5. Starten Sie den Docker-Daemon und überprüfen Sie, ob er auf das richtige Verzeichnis verweist:

systemctl status docker

In einer der Zeilen der Ausgabe sollten wir sehen:

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

Wir haben uns vergewissert, dass die Option an den Daemon übergeben wurde, jetzt überprü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 beginnt das Interessante: DB, MQ, alles funktioniert gut! Die Datenbank ist intakt, alles läuft... außer nginx. Wir haben eine eigene nginx-Build-Version mit Kerberos und anderen Komponenten. Und das Durchsehen der Container-Logs zeigte, dass er nicht in /var/tmp schreiben konnte – Berechtigung verweigert. Ich massiere meine Schläfen und versuche, die Situation zu analysieren... Wie kann das sein? Das Docker-Image hat sich doch nicht geändert. Wir haben nur das Verzeichnis verschoben. Es hat immer funktioniert, und jetzt das... Zum Experiment ging ich manuell in den Container und änderte die Berechtigungen für dieses Verzeichnis auf root, root 755, gab root, root 777. Und alles funktionierte wieder... In meinem Kopf regte sich der Gedanke – das kann nicht wahr sein... Ich dachte, vielleicht habe ich etwas übersehen...

Ich entschied, dass wir beim Verschieben die Dateiberechtigungen verloren hatten. Wir stoppten die Anwendung, den Docker-Daemon, löschten das neue Verzeichnis und führten eine Kopie des Verzeichnisses /var/lib/docker durch, wobei wir rsync -a.

verwenden. Ich dachte, jetzt ist alles in Ordnung, starten wir Docker und die Anwendung.

Und… das Problem bleibt bestehen… Mein Auge zuckt. Ich bin schnell zur Konsole meiner virtuellen Maschine geeilt, wo ich verschiedene Tests durchführe. Ich hatte dieses Nginx-Image, und ich bin in den Container gegangen. Dort stehen die Berechtigungen für das Verzeichnis /var/tmp auf root, root 777. Also die gleichen, die ich manuell einstellen 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 erneut aus dem Registry heruntergeladen, das aus verschiedenen Gründen auf derselben Maschine liegt. Und das Problem bleibt… Jetzt zuckt mein zweites Auge.

Ich kann mich nicht mehr erinnern, welche Gedanken mir durch den Kopf gingen, abgesehen von dem Geschrei „AAAAAAA“ und ähnlichem. Es ist 4 Uhr morgens, ich habe die Docker-Quellcodes durchgesehen, um das Prinzip der Schicht-Hashierung zu verstehen. Ich habe die dritte Dose Energydrink geöffnet. Und schließlich wurde mir klar, dass die Hashierung nur die Datei und ihren Inhalt berücksichtigt, aber KEINE ZUGRIFFSRECHTE! Auf mysteriöse Weise sind unsere Berechtigungen beschädigt worden, obwohl selinux deaktiviert ist, keine acl verwendet werden, und der sticky bit nicht gesetzt ist.

Ich habe das lokale Image gelöscht, auch das Image aus dem Docker-Registry entfernt und es erneut hochgeladen. Und alles funktionierte. Das scheint zu bedeuten, dass die Berechtigungen beim Transfer beschädigt wurden, sowohl im lokalen Image als auch im Image im Registry. Wie ich bereits erwähnt habe, lag es aus verschiedenen Gründen auf diesem Gerät. Folglich im selben Verzeichnis /var/lib/docker.

Und um die Frage vorweg zu nehmen, ob wir versucht haben, Docker wieder auf das alte Verzeichnis zu lenken — nein, wir haben es nicht versucht, leider erlaubten es die Umstände nicht. Außerdem wollte ich wirklich verstehen, was passiert war.

Nach dem Schreiben dieses Artikels erscheint mir die Lösung des Problems offensichtlich, aber zum Zeitpunkt der Analyse sah es nicht so aus. Ich habe ehrlich gegoogelt und keine ähnlichen Situationen gefunden.

Fazit: Ich habe das Problem gelöst, aber die Ursache nicht verstanden =(

Wenn jemand ähnliche Vermutungen über die möglichen Ursachen dieses Problems hat — ich würde mich sehr freuen, in den Kommentaren von euch zu hören!

Quelle: habr.com