Historia e problemit të migrimit të ruajtjes docker (docker root)

Para disa ditësh u vendos që në një nga serverët të nxirrej docker storage (direktori ku docker ruan të gjitha skedarët e kontejnerëve dhe imazheve) në një pjesë të veçantë, që
kishte kapacitet më të madh. Detyra, duket e thjeshtë dhe nuk parashikonte ndonjë problem


Po fillojmë:

1. Ndalo dhe mbyll të gjithë kontejnerët e aplikacionit tonë:

docker-compose down

nëse ka shumë kontejnerë dhe ata janë në compose të ndryshme, mund të bëjmë kështu:

docker rm -f $(docker ps -q)

2. Ndalo demonin docker:

systemctl stop docker

3. Transfero katalogun në vendin e duhur:

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

4. Informojmë demonin docker që të shikojë në drejtorinë e re. Ka disa mundësi: ose përmes flag-ut -g të tregoni demonit për rrugën e re, ose konfigurimet systemd që përdorëm. Ose një simbolikë. Nuk do ta shpjegoja në detaje, në internet ka mjaft manualesh për transferimin e docker root në një vend të ri.

5. Nisim demonin docker dhe mbajmë nën vëzhgim për të parë nëse shikon aty ku duhet:

systemctl status docker

Në një nga rreshtat e daljes duhet të shohim:

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

Siguruam që opsioni iu dërgua demonit, tani do të verifikojmë nëse e aplikoi atë (faleminderit inkvizitor68sl)!

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

6. Nisim aplikacionin tonë:

docker-compose up -d

7. Kontrollojmë

Dhe kĂ«tu fillon pjesa mĂ« interesante, SGBD, MQ, gjithçka nĂ« rregull! Baza Ă«shtĂ« e plotĂ«, gjithçka funksionon
 pĂ«rveç nginx. Ne kemi ndĂ«rtimin tonĂ« tĂ« nginx me Kerberos dhe kurtiçanĂ«t. Dhe shikimi i logĂ«ve tĂ« kontejnerit tregoi se ai nuk mund tĂ« shkruajĂ« nĂ« /var/tmp — Permission denied. Po i bĂ«ja masazhe gishtĂ«rinjve dhe pĂ«rpiqesha tĂ« analizoja situatĂ«n
 Si Ă«shtĂ« e mundur? Imazhi docker nuk ka ndryshuar. Ne thjesht e kemi transferuar direktorinĂ«. GjithmonĂ« ka funksionuar, dhe tani
 PĂ«r eksperiment hova dorĂ«n nĂ« kontejner dhe ndryshova tĂ« drejtat nĂ« kĂ«tĂ« katalog, ishin root, root 755, dhashĂ« root, root 777. Dhe gjithçka filloi
 NĂ« mendje mu shfaq njĂ« mendim — Ă«shtĂ« ndonjĂ« gabim
 Mendova, ndoshta kam lĂ«nĂ« ndonjĂ« gjĂ« jashtë 

Vendosa se kemi humbur të drejtat e aksesit në skedarë gjatë transferimit. Ndalëm aplikacionin, demonin docker, fshimë drejtorinë e re dhe bëmë kopjimin e drejtorisë /var/lib/docker duke përdorur rsync -a.

Mendoj, tani sigurisht që gjithçka është në rregull, e nisim dockerin, aplikacionin.

Eh... problemi mbeti... Kam sy të tërhiqem syri. Shkela në konsolën e virtuales time, ku kryej disa teste të ndryshme, kisha këtë imazh nginx, dhe hyra brenda kontejnerit, dhe këtu në katalogun /var/tmp të drejtat janë root, root 777. Pra, janë të njëjtat si ato që më duhej t'i vendosja me dorë. Por imazhet janë identike!

Kudo është përdorur FS xfs.

E krahasova nëpërmjet komandës

docker inspect my-nginx:12345

TĂ« gjitha hash-t janĂ« identike, çdo gjĂ« njĂ« nĂ« njĂ«. Ashtu si nĂ« server, ashtu edhe nĂ« virtualen time. Hoqa imazhin lokal nginx dhe e mora pĂ«rsĂ«ri nga registry, i cili pĂ«r disa arsye ndodhet nĂ« kĂ«tĂ« makinĂ« tĂ« njĂ«jtĂ«. Dhe problemi Ă«shtĂ« po ai
 Tani syri im i dytĂ« po tĂ«rhiqet.

Nuk po e mbaj mend, çfarĂ« mendimesh ishin nĂ« kokĂ«n time, pĂ«rveç ulĂ«rimave "AAAAAA" dhe gjĂ«rave tĂ« tjera. NĂ« rrugĂ« Ă«shtĂ« ora 4 nĂ« mĂ«ngjes, iu kam drejtuar burimeve tĂ« docker pĂ«r tĂ« kuptuar parimin e hash-it tĂ« shtresave tĂ« imazhit. Hap njĂ« kavanoz tĂ« tretĂ« energjizues. Dhe nĂ« fund e kuptova, se hash-i merr parasysh vetĂ«m skedarin, pĂ«rmbajtjen e tij, por NËN QASJE! KĂ«shtu qĂ«, nĂ« njĂ« mĂ«nyrĂ« misterioze, tĂ« drejtat tona u prishĂ«n, pĂ«r mĂ« tepĂ«r selinux Ă«shtĂ« çaktivizuar, acl nuk pĂ«rdoren, sticky bit nuk Ă«shtĂ« aktiv.

Hoqa imazhin lokal, gjithashtu e hoqa imazhin nga docker registry dhe e ngarkova përsëri. Dhe gjithçka funksionoi. Kështu që, gjatë transferit, të drejtat u prishën, si brenda imazhit lokal, ashtu edhe brenda imazhit të vendosur në registry. Siç e përmenda, për disa arsye, ai ishte në këtë makinë të njëjtë. Dhe si rezultat, në një katalog /var/lib/docker.

Dhe duke pritur pyetjen, nĂ«se kemi provuar tĂ« kthejmĂ« docker nĂ« katalg tinĂ« e vjetĂ«r — jo, nuk e provuam, fatkeqĂ«sisht, rrethanat nuk e lejuan. Dhe gjithashtu, dĂ«shiroja shumĂ« tĂ« kuptoja.

Pas shkrimit të këtij artikulli, zgjidhja e problemit më duket e qartë, por në momentin e shqyrtimit nuk ishte kështu. Me sinqeritet kërkova në Google, dhe nuk gjetëm situata të ngjashme.

Përfundimi: e zgjida problemin, shkakun nuk e kuptova =(

NĂ«se dikush e di, e dyshon, kishte ndonjĂ« vizion pĂ«r shkaqet e mundshme tĂ« kĂ«tij problemi — do tĂ« isha jashtĂ«zakonisht i lumtur t'i shihja komentet tuaja!

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster