Istoria problemei privind migrarea stocării docker (docker root)

Cu doar câteva zile în urmă, s-a decis să mutăm stocarea Docker (directorul în care Docker păstrează toate fișierele containerelor și imaginile) pe o partiție separată care
avea o capacitate mai mare. Sarcina părea, de fapt, trivială și nu prevestea nimic rău...

Să începem:

1. Oprim și eliminăm toate containerele aplicației noastre:

docker-compose down

dacă sunt multe containere și sunt în compuneri diferite, se poate așa:

docker rm -f $(docker ps -q)

2. Oprim demonul Docker:

systemctl stop docker

3. Mutăm directorul în locul necesar:

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

4. Informăm demonul Docker să privească în noua direcție. Aici sunt mai multe opțiuni: fie prin flag-ul -g, fie prin configurațiile systemd, pe care le-am folosit. Sau un symlink. Nu mă voi extinde asupra acestui lucru, pe internet sunt o mulțime

de manuale despre mutarea rădăcinii Docker într-un nou loc.

5. Pornim demonul Docker și ne asigurăm că se îndreaptă unde trebuie:

systemctl status docker

În una dintre liniile de ieșire ar trebui să vedem:

├─19493 /usr/bin/dockerd --data-root=/docker/data/storage Ne-am asigurat că am transmis opțiunea demonului, acum să verificăm dacă a aplicat-o (mulțumim)!

inkvizitor68sl 

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

docker-compose up -d

6. Pornim aplicația noastră:

7. Verificăm Și aici începe partea cea mai interesantă, SGBD, MQ, totul este bine! Baza de date e întreagă, totul funcționează... cu excepția Nginx. Avem o construcție proprie Nginx cu Kerberos și curtezane. Iar examinarea jurnalelor containerului a arătat că nu poate scrie în /var/tmp—Permission denied. Îmi răsucesc degetele pe tâmple și încerc să analizez situația... Cum așa? Imaginea Docker nu s-a schimbat. Am mutat doar directorul. A funcționat întotdeauna, și acum... Ca experiment, am intrat manual în container și am schimbat permisiunile pentru acest director, erauroot, root 755 , am datroot, root 777

. Și totul a început să funcționeze... În minte mi-a apărut gândul — absurd... M-am gândit că poate am omis ceva... Am decis că am pierdut permisiunile de acces la fișiere în timpul mutării. Am oprit aplicația, demonul Docker, am șters noul director și am realizat copierea directorului /var/lib/docker folosind.

rsync -a Cred că acum totul este în regulă, pornim Docker, aplicația.

Și… problema a rămas… Mi s-a stricat un ochi. Am fugit la consola virtualului meu, unde rulez diverse teste, aveam această imagine nginx, și am intrat în container, și aici în directorul /var/tmp permisiunile sunt root, root 777. Adică la fel cum trebuia să le seteze manual. Dar imaginile sunt identice!

FS xfs a fost folosit peste tot.

Am comparat prin comanda

docker inspect my-nginx:12345

Toate hash-urile sunt identice, totul este la fel. Atât pe server, cât și pe virtualul meu. Am șters imaginea locală nginx și am descărcat-o din nou de la registry, care din diverse motive se află pe aceeași mașină. Și problema este aceeași… Acum mi s-a stricat și celălalt ochi.

Nu mai știu ce gânduri aveam în cap, în afară de strigăte «AAAAAA» și altele asemenea. Afară sunt 4 dimineața, am început să analizez sursele Docker pentru a înțelege principiul hashării stratelor imaginii. Am deschis a treia doză de energizant. Și, în final, mi-am dat seama că hasharea ia în considerare doar fișierul, conținutul acestuia, dar NU PERMISIUNILE DE ACCES! Asta înseamnă că, într-un mod misterios, permisiunile noastre s-au stricat, deși selinux este dezactivat, acl nu sunt utilizate, sticky bit nu este prezent.

Am șters imaginea locală, de asemenea am șters imaginea din docker registry și am încărcat-o din nou. Și totul a funcționat. Se pare că, la transfer, permisiunile s-au stricat, atât în interiorul imaginii locale, cât și în imaginea aflată în registry. Așa cum am spus, din diverse motive se afla pe aceeași mașină. Și, ca urmare, într-un director /var/lib/docker.

Și anticipând întrebarea, nu am încercat să readucem Docker la vechiul director — nu, nu am încercat, din păcate, condițiile nu au permis. Și mi-aș fi dorit mult să înțeleg.

După scrierea acestui articol, soluția problemei mi se pare evidentă, dar în momentul analizei nu părea așa. Am căutat sincer și nu am găsit situații asemănătoare.

Rezultatul: am rezolvat problema, dar nu am înțeles cauza =(

Dacă cineva știe sau are o idee despre posibilele cauze ale acestei probleme — aș fi extrem de recunoscător pentru comentarii!

Sursa: habr.com

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster