Spätestens vor ein paar Tagen wurde auf einem der Server entschieden, den Docker-Speicher (das Verzeichnis, in dem der Docker alle Dateien von Containern und Images speichert) auf eine separate Partition zu verschieben
besaß mehr Kapazität. Die Aufgabe scheint trivial zu sein und war kein Problem ...
Erste Schritte:
1. Halten Sie an und töten Sie alle Container unserer Anwendung:
docker-compose down
Wenn es viele Container gibt und diese sich in unterschiedlicher Zusammensetzung befinden, können Sie dies 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 Speicherort:
cp -r /var/lib/docker /docker/data/storage
4. Wir informieren den Dämon des Dockers, in einem neuen Verzeichnis zu suchen. Es gibt verschiedene Möglichkeiten: Verwenden Sie entweder das Flag -g, um den Dämon auf einen neuen Pfad zu verweisen, oder die von uns verwendeten systemd-Konfigurationen. Nun, oder Symlink. Ich werde nicht viel malen, das Internet ist
voll von Handbüchern zum Portieren von Docker-Root an einen neuen Ort.
5. Wir starten den Docker-Dämon und sehen, dass er dort aussieht, wo er sein sollte:
systemctl status docker
In einer der Ausgabezeilen sollten wir 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 sie angewendet wurde (danke
inkvizitor68sl ).
docker info | awk '/Root Dir/ {print $NF}'
6. Wir starten unsere Bewerbung:
docker-compose up -d
7. Überprüfen Sie
Und hier beginnt der Spaß, DBMS, MQ, alles ist gut! Die Basis ist intakt, alles funktioniert ... bis auf Nginx. Wir haben unsere eigene Nginx-Baugruppe mit Kerberos
und Kurtisanen . Das Anzeigen der Protokolle des Containers zeigte an, dass er nicht in / var / tmp schreiben konnte - Berechtigung verweigert. Ich strecke meine Finger mit Whisky aus und versuche die Situation zu analysieren ... Wie ist das? 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 ... Um zu experimentieren, ging ich mit Stiften in den Container und änderte die Rechte an diesem Verzeichnis, es gab
root, root 755 , gab
root, root 777 . Und alles begann ... Ein Gedanke klang in meinem Kopf - eine Art Unsinn ... Ich dachte, vielleicht habe ich etwas nicht berücksichtigt ...
Ich entschied, dass uns die Zugriffsrechte auf die Dateien während der Übertragung gefallen haben. Sie haben die Anwendung, den Docker-Daemon, gestoppt, das neue Verzeichnis gelöscht und bereits mit
rsync -a eine Kopie des Verzeichnisses / var / lib / docker erstellt.
Ich denke, jetzt ist alles in Ordnung. Wir erhöhen den Docker, die Anwendung.
III ... das Problem bleibt ... Mein Auge zuckte. Ich eilte zur Konsole meiner virtuellen Maschine, wo ich verschiedene Tests durchführe. Ich hatte dieses Nginx-Image und bin in den Container geklettert. Hier befinden sich die Root- und Root-777-Rechte im Verzeichnis / var / tmp. Das sind dieselben, die ich mit meinen Händen einrichten musste . Aber die Bilder sind identisch!
Überall verwendete FS xfs.Ich habe durch den Befehl verglichen
docker inspect my-nginx:12345
Alle Hashes sind identisch, alle eins zu eins. Sowohl auf dem Server als auch auf meiner Virtualka. Ich habe das lokale Nginx-Image gelöscht und erneut mit der Registrierung gespoolt, die sich aus mehreren Gründen auf demselben Computer befindet. Und das Problem ist das gleiche ... Jetzt zuckte mein zweites Auge.
Ich kann mich nicht erinnern, welche Gedanken in meinem Kopf waren, abgesehen von den Schreien von "AAAAAAA" und anderen Dingen. Auf der Straße um 4 Uhr morgens wurden die Docker-Quellen verwendet, um das Prinzip des Hashing von Bildebenen zu verstehen. Er öffnete die dritte Energiedose. Und am Ende wurde mir klar, dass beim Hashing nur die Datei, ihr Inhalt, aber
nicht das Zugriffsrecht berücksichtigt werden! Das heißt, auf mysteriöse Weise wurden Rechte geschlagen und Selinux ist deaktiviert, acl wird nicht verwendet, klebriges Bit ist nicht vorhanden.
Ich habe das lokale Image gelöscht, auch das Image aus der Docker-Registrierung gelöscht und erneut gestartet. Und es hat funktioniert. Es stellt sich heraus, dass während der Übertragung die Rechte sowohl innerhalb des lokalen Bildes als auch innerhalb des in der Registrierung liegenden Bildes geschlagen wurden. Wie gesagt, aus mehreren Gründen befand es sich im selben Auto. Und als Ergebnis in einem Verzeichnis / var / lib / docker.
Und die Frage vorwegzunehmen, ob sie versuchten, den Blick des Hafenarbeiters auf den alten Katalog zurückzubringen - nein, die Umstände ließen es leider nicht zu. Ja, und wollte es wirklich herausfinden.
Nach dem Schreiben dieses Artikels scheint mir die Lösung des Problems offensichtlich zu sein, aber zum Zeitpunkt der Analyse schien dies nicht der Fall zu sein. Ich habe ehrlich gegoogelt und keine ähnlichen Situationen gefunden.
Fazit: Ich habe das Problem gelöst, ich habe den Grund nicht verstanden = (
Wenn jemand eine Vision über die möglichen Ursachen dieses Problems kennt / vermutet / hatte - ich würde mich sehr freuen, Sie in den Kommentaren zu sehen!