Istoricul problemei de migrare a stocării docker (rădăcină docker)

Nu mai mult de câteva zile în urmă, s-a decis ca unul dintre servere să mute spațiul de stocare Docker (directorul în care docker stochează toate fișierele container și imagini) într-o secțiune separată, care
avea o capacitate mai mare. Sarcina părea banală și nu prevestește probleme...

Noțiuni introductive:

1. Opriți și ucideți toate containerele aplicației noastre:

docker-compose down

dacă există o mulțime de recipiente și sunt în compoziții diferite, puteți face acest lucru:

docker rm -f $(docker ps -q)

2. Opriți demonul docker:

systemctl stop docker

3. Mutați directorul în locația dorită:

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

4. Spunem demonului docker să caute în noul director. Există mai multe opțiuni: fie folosiți steag-ul -g pentru a indica demonul către o nouă cale, fie configurațiile systemd, pe care le-am folosit. Sau un link simbolic. Nu voi intra în prea multe detalii despre asta, este pe internet. deplin manuale despre mutarea docker root într-o locație nouă.

5. Porniți demonul docker și asigurați-vă că arată în locul potrivit:

systemctl status docker

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

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

Ne-am asigurat că opțiunea a fost transmisă demonului, acum să verificăm dacă a aplicat-o (mulțumesc inkvizitor68sl)!

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

6. Să începem aplicația noastră:

docker-compose up -d

7. Verificați

Și aici începe distracția, DBMS, MQ, totul este în regulă! Baza de date este intactă, totul funcționează... cu excepția nginx. Avem propria noastră versiune nginx cu Kerberos și curtezane. Și vizualizarea jurnalelor containerului a indicat că nu poate scrie în /var/tmp - Permisiune refuzată. Îmi frământ tâmplele cu degetele și încerc să analizez situația... Cum este posibil acest lucru? Imaginea Docker nu s-a schimbat. Tocmai am mutat directorul. Mereu a funcționat și iată-l pentru tine... De dragul experimentului, am intrat cu mâinile în container și am schimbat drepturile la acest director, au fost rădăcină, rădăcină 755, a dat rădăcină, rădăcină 777. Și totul a început... Un gând a început să sune în capul meu - un fel de prostie... M-am gândit, ei bine, poate nu am ținut cont de ceva...

Am decis că ne-am îndrăgostit de drepturile de acces la fișiere în timpul transferului. Am oprit aplicația, demonul docker, am șters noul director și am copiat directorul /var/lib/docker folosind rsync -a.

Cred că totul este bine acum, să ridicăm aplicația Docker.

Aaand... problema a rămas... Ochiul mi-a tresărit. M-am repezit la consola mașinii mele virtuale, unde rulez diverse teste, aveam această imagine nginx și m-am urcat în interiorul containerului, iar aici drepturile la directorul /var/tmp sunt root, root 777. Adică, la fel ca a trebuit sa setez manual. Dar imaginile sunt identice!

Sistemul de fișiere xfs a fost folosit peste tot.

Am comparat folosind comanda

docker inspect my-nginx:12345

Toate hashe-urile sunt identice, toate unu la unu. Atât pe server, cât și pe mașina mea virtuală. Am șters imaginea locală nginx și am scos-o din nou din registry, care din mai multe motive se află pe aceeași mașină. Și problema este aceeași... Acum al doilea ochi îmi zvâcnește.

Nu-mi mai amintesc ce gânduri erau în capul meu, în afară de strigătul „AAAAAAAAA” și alte lucruri. Era ora 4 dimineața, iar codul sursă Docker a fost folosit pentru a înțelege principiul hashingului straturilor de imagine. A deschis a treia cutie de băutură energizantă. Și până la urmă mi-a dat seama că hashingul ia în considerare doar fișierul, conținutul acestuia, dar NU DREPTURI DE ACCES! Adică, într-un fel misterios, drepturile noastre s-au pierdut, selinux este dezactivat, acl nu este folosit și nu există nici un sticky bit.

Am șters imaginea locală, am șters și imaginea din registrul docker și am împins-o din nou. Și totul a funcționat. Se dovedește că în timpul transferului drepturile s-au pierdut, atât în ​​interiorul imaginii locale, cât și în interiorul imaginii aflate în registru. După cum am spus deja, din mai multe motive era situat pe aceeași mașină. Și, ca rezultat, într-un singur director /var/lib/docker.

Și anticipând întrebarea dacă au încercat să întoarcă privirea docker-ului către vechiul director - nu, nu au încercat, din păcate, circumstanțele nu le-au permis. Da, și chiar voiam să-mi dau seama.

După ce am scris acest articol, soluția problemei mi se pare evidentă, dar la momentul analizei nu mi s-a părut așa. Sincer, am căutat pe Google și nu am găsit situații similare.

Rezultat: Am rezolvat problema, încă nu înțeleg motivul =(

Dacă cineva știe, ghicește, a avut o viziune despre posibilele cauze ale acestei probleme, voi fi extrem de bucuros să aud de la tine în comentarii!

Sursa: www.habr.com