Geschichte des Docker-Speichermigrationsproblems (Docker-Root)

Vor nicht mehr als ein paar Tagen wurde auf einem der Server beschlossen, den Docker-Speicher (das Verzeichnis, in dem Docker alle Container- und Bilddateien speichert) in einen separaten Abschnitt zu verschieben
hatte eine größere Kapazität. Die Aufgabe schien trivial und ließ keine Schwierigkeiten ahnen ...

Lass uns anfangen:

1. Stoppen und beenden Sie alle Container unserer Anwendung:

docker-compose down

Wenn viele Behälter vorhanden sind und diese unterschiedliche Zusammensetzungen haben, können Sie Folgendes tun:

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. Wir weisen den Docker-Daemon an, im neuen Verzeichnis nachzuschauen. Es gibt mehrere Optionen: Entweder verwenden Sie das Flag -g, um den Daemon auf einen neuen Pfad zu verweisen, oder systemd configs, die wir verwendet haben. Oder ein Symlink. Ich werde nicht zu sehr darauf eingehen, es steht im Internet. voll von Handbücher zum Verschieben des Docker-Roots an einen neuen Speicherort.

5. Starten Sie den Docker-Daemon und stellen Sie sicher, dass er an der richtigen Stelle angezeigt wird:

systemctl status docker

In einer der Ausgabezeilen sollten wir Folgendes sehen:

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

Wir haben sichergestellt, dass die Option an den Daemon übergeben wurde. Jetzt prüfen wir, ob er sie angewendet hat (danke). inkvizitor68sl)!

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

6. Beginnen wir mit unserer Bewerbung:

docker-compose up -d

7. Überprüfung

Und hier beginnt der Spaß, DBMS, MQ, alles ist gut! Die Datenbank ist intakt, alles funktioniert... außer Nginx. Wir haben unseren eigenen Nginx-Build mit Kerberos und Kurtisanen. Und beim Betrachten der Containerprotokolle wurde festgestellt, dass nicht in /var/tmp geschrieben werden kann – Berechtigung verweigert. Ich knete meine Schläfen mit den Fingern und versuche die Situation zu analysieren... Wie ist das möglich? Das Docker-Image hat sich nicht geändert. Wir haben gerade das Verzeichnis verschoben. Es hat immer funktioniert, und hier ist es für Sie ... Aus Versuchsgründen bin ich mit meinen Händen in den Container gegangen und habe die Rechte an diesem Verzeichnis geändert, die es gab root, root 755, gab root, root 777. Und alles begann ... Ein Gedanke begann in meinem Kopf zu klingen - eine Art Unsinn ... Ich dachte, vielleicht habe ich etwas nicht berücksichtigt ...

Ich kam zu dem Schluss, dass wir uns in die Zugriffsrechte auf die Dateien während der Übertragung verliebt haben. Wir haben die Anwendung, den Docker-Daemon, gestoppt, das neue Verzeichnis gelöscht und das Verzeichnis /var/lib/docker mit kopiert rsync -a.

Ich denke, jetzt ist alles in Ordnung. Lassen Sie uns die Docker-Anwendung starten.

Uuund... das Problem blieb bestehen... Mein Auge zuckte. Ich eilte zur Konsole meiner virtuellen Maschine, wo ich verschiedene Tests durchführte, ich hatte dieses Nginx-Image und bin in den Container geklettert, und hier sind die Rechte für das Verzeichnis /var/tmp root, root 777. Das heißt das Gleiche, was ich manuell einstellen musste. Aber die Bilder sind identisch!

Überall wurde das xfs-Dateisystem verwendet.

Ich habe mit dem Befehl verglichen

docker inspect my-nginx:12345

Alle Hashes sind identisch, alle 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 der Registrierung abgerufen, die sich aus mehreren Gründen auf demselben Computer befindet. Und das Problem ist das gleiche... Jetzt zuckt mein zweites Auge.

Ich erinnere mich nicht mehr daran, welche Gedanken mir durch den Kopf gingen, außer „AAAAAAAAA“ zu rufen und andere Dinge. Es war 4 Uhr morgens und der Docker-Quellcode wurde verwendet, um das Prinzip des Hashing von Bildebenen zu verstehen. Habe die dritte Dose Energydrink geöffnet. Und am Ende wurde mir klar, dass Hashing nur die Datei und ihren Inhalt berücksichtigt, aber KEINE ZUGRIFFSRECHTE! Das heißt, auf mysteriöse Weise sind unsere Rechte verloren gegangen, Selinux ist deaktiviert, ACL wird nicht verwendet und es gibt kein Sticky-Bit.

Ich habe das lokale Image gelöscht, das Image auch aus der Docker-Registrierung gelöscht und es erneut gepusht. Und alles hat funktioniert. Es stellt sich heraus, dass bei der Übertragung die Rechte verloren gegangen sind, sowohl innerhalb des lokalen Images als auch innerhalb des in der Registry liegenden Images. Wie ich bereits sagte, befand es sich aus mehreren Gründen im selben Auto. Und als Ergebnis in einem Verzeichnis /var/lib/docker.

Und im Vorgriff auf die Frage, ob sie versucht haben, den Blick des Hafenarbeiters wieder auf das alte Verzeichnis zu richten – nein, sie haben es nicht versucht, leider ließen die Umstände dies nicht zu. Ja, und ich wollte es unbedingt herausfinden.

Nach dem Schreiben dieses Artikels scheint mir die Lösung des Problems offensichtlich zu sein, zum Zeitpunkt der Analyse schien sie jedoch nicht so. Ehrlich gesagt habe ich gegoogelt und keine ähnlichen Situationen gefunden.

Ergebnis: Ich habe das Problem gelöst, ich verstehe den Grund immer noch nicht =(

Wenn jemand die möglichen Ursachen dieses Problems kennt, vermutet oder eine Vorstellung davon hat, würde ich mich sehr freuen, von Ihnen in den Kommentaren zu hören!

Source: habr.com