Geskiedenis van die docker berging migrasie probleem (docker root)

Nie meer as 'n paar dae gelede nie, is daar op een van die bedieners besluit om docker-berging (die gids waar docker alle houer- en beeldlêers stoor) na 'n aparte afdeling te skuif, wat
groter kapasiteit gehad. Die taak het onbenullig gelyk en het nie moeilikheid voorspel nie...

Aan die begin:

1. Stop en maak alle houers van ons toepassing dood:

docker-compose down

as daar baie houers is en hulle in verskillende samestellings is, kan jy dit doen:

docker rm -f $(docker ps -q)

2. Stop die docker daemon:

systemctl stop docker

3. Skuif die gids na die verlangde ligging:

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

4. Ons sê vir die docker daemon om in die nuwe gids te kyk. Daar is verskeie opsies: óf gebruik die -g vlag om die daemon na 'n nuwe pad te wys, óf systemd configs, wat ons gebruik het. Of 'n simboliek. Ek gaan nie te veel hieroor in nie, dit is op die internet. vol handleidings oor die verskuiwing van docker-wortel na 'n nuwe plek.

5. Begin die docker daemon en maak seker dit lyk op die regte plek:

systemctl status docker

In een van die uitvoerlyne behoort ons te sien:

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

Ons het seker gemaak dat die opsie na die daemoon oorgedra is, kom ons kyk nou of dit dit toegepas het (dankie inkvisitor68sl)!

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

6. Kom ons begin ons toepassing:

docker-compose up -d

7. Kontroleer

En hier begin die pret, DBMS, MQ, alles is reg! Die databasis is ongeskonde, alles werk ... behalwe nginx. Ons het ons eie nginx-gebou met Kerberos en courtisane. En deur die houerlogboeke te kyk, het dit aangedui dat dit nie na /var/tmp kan skryf nie - Toestemming geweier. Ek knie my slape met my vingers en probeer die situasie ontleed... Hoe is dit moontlik? Die Docker-beeld het nie verander nie. Ons het sopas die gids geskuif. Dit het altyd gewerk, en hier is dit vir jou... Ter wille van eksperiment het ek met my hande in die houer gegaan en die regte op hierdie gids verander, daar was wortel, wortel 755, gegee wortel, wortel 777. En alles het begin ... 'n Gedagte het in my kop begin opklink - 'n soort nonsens ... Ek het gedink, wel, miskien het ek nie iets in ag geneem nie ...

Ek het besluit dat ons verlief geraak het op die toegangsregte tot die lêers tydens die oordrag. Ons het die toepassing, die docker daemon gestop, die nuwe gids uitgevee en die /var/lib/docker-gids gekopieer met rsync -a.

Ek dink alles is nou reg, kom ons verhoog die Docker-toepassing.

Aaand... die probleem het gebly... My oog ruk. Ek het na die konsole van my virtuele masjien gehaas, waar ek verskeie toetse uitvoer, ek het hierdie nginx-beeld gehad, en ek het in die houer geklim, en hier is die regte op die /var/tmp-gids root, root 777. Dit wil sê, die dieselfde as wat ek met die hand moes stel. Maar die beelde is identies!

Die xfs-lêerstelsel is oral gebruik.

Ek het vergelyk met behulp van die opdrag

docker inspect my-nginx:12345

Alle hashes is identies, almal een tot een. Beide op die bediener en op my virtuele masjien. Ek het die plaaslike nginx-beeld uitgevee en dit weer uit die register gehaal, wat om 'n aantal redes op dieselfde masjien is. En die probleem is dieselfde... Nou ruk my tweede oog.

Ek onthou nie meer watter gedagtes in my kop was nie, behalwe om “AAAAAAAAAA” en ander goed te skree. Dit was 4 uur in die oggend, en die Docker-bronkode is gebruik om die beginsel van hashing van beeldlae te verstaan. Die derde blikkie energiedrankie oopgemaak. En op die ou end het dit tot my deurgedring dat hashing net die lêer, die inhoud daarvan, maar in ag neem NIE TOEGANGSREGTE NIE! Dit wil sê, op een of ander geheimsinnige manier is ons regte verlore, selinux is gedeaktiveer, acl word nie gebruik nie, en daar is geen taai bietjie nie.

Ek het die plaaslike prent uitgevee, ook die prent uit die docker-register uitgevee en dit weer gedruk. En alles het gewerk. Dit blyk dat tydens die oordrag die regte verlore gegaan het, beide binne die plaaslike beeld en binne die beeld wat in die register lê. Soos ek reeds gesê het, was dit om verskeie redes op dieselfde motor geleë. En as gevolg hiervan, in een gids /var/lib/docker.

En vooruit op die vraag of hulle probeer het om die dokwerker se blik na die ou gids terug te keer - nee, hulle het nie probeer nie, helaas, omstandighede het dit nie toegelaat nie. Ja, en ek wou dit regtig uitvind.

Na die skryf van hierdie artikel lyk die oplossing vir die probleem vir my voor die hand liggend, maar ten tyde van die ontleding het dit nie so gelyk nie. Eerlik, ek het gegoogle en nie soortgelyke situasies gevind nie.

Resultaat: Ek het die probleem opgelos, ek verstaan ​​steeds nie die rede nie =(

As iemand weet, raai, het 'n visie oor die moontlike oorsake van hierdie probleem, sal ek baie bly wees om van jou te hoor in die kommentaar!

Bron: will.com