De geschiedenis van het probleem van het verplaatsen van docker storage (docker root)

Enige dagen geleden werd besloten om de Docker-opslag (de map waarin Docker alle containerbestanden en -images opslaat) op een aparte partitie te plaatsen die
meer capaciteit had. De taak leek triviaal en beloofde niets te goeds…

Laten we beginnen:

1. Stop en verwijder alle containers van onze applicatie:

docker-compose down

Als er veel containers zijn en ze in verschillende compose-bestanden staan, kan dit ook:

docker rm -f $(docker ps -q)

2. Stop de Docker-daemon:

systemctl stop docker

3. Verplaats de map naar de juiste locatie:

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

4. Geef de Docker-daemon door dat hij naar de nieuwe directory moet kijken. Er zijn verschillende opties: ofwel de daemon naar het nieuwe pad wijzen met de -g vlag, of met systemd-configuraties, wat wij hebben gebruikt. Of als symbolische link. Ik zal dit niet in detail beschrijven, er zijn genoeg handleidingen op internet over het verplaatsen van de Docker-root naar een nieuwe locatie.

5. Start de Docker-daemon weer, en controleer of hij naar de juiste locatie kijkt:

systemctl status docker

In een van de regels van de uitvoer zouden we moeten zien:

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

We hebben gecontroleerd dat we de optie aan de daemon hebben doorgegeven, nu controleren we of hij deze heeft toegepast (dank aan inkvizitor68sl)!

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

6. Start onze applicatie:

docker-compose up -d

7. Controleer het

En hier begint het interessante, DB, MQ, alles werkt goed! Database is intact, alles functioneert… behalve nginx. We hebben onze eigen nginx-build met Kerberos en courtesans. En het bekijken van de logs van de container gaf aan dat hij niet kon schrijven naar /var/tmp - Toegang geweigerd. Ik wrijf mijn slapen en probeer de situatie te analyseren… Hoe kan dit? Het Docker-image is immers niet veranderd. We hebben alleen de directory verplaatst. Het heeft altijd gewerkt, en nu ineens… Uit nieuwsgierigheid ben ik de container ingegaan en heb ik de rechten op deze map gewijzigd, waren root, root 755, gaf root, root 777. En alles werkte weer… In mijn hoofd hoorde ik een gedachte – dit is onzin… Ik dacht, misschien heb ik iets over het hoofd gezien…

Ik besloot dat we waarschijnlijk de bestandsrechten bij het verplaatsen hadden verloren. We stopten de applicatie, de Docker-daemon, verwijderden de nieuwe directory en voerden een kopie uit van de directory /var/lib/docker met behulp van rsync -a.

Ik dacht dat alles nu zeker goed was, we starten Docker en de applicatie.

Tja… het probleem blijft bestaan… Mijn oog trilt. Ik sprintte naar de console van mijn virtuele machine, waar ik verschillende tests uitvoer. Ik had dit nginx-image en ik ging het container in, en daar had de map /var/tmp de rechten root, root 777. Dat zijn dezelfde rechten die ik handmatig moest instellen. Maar de images zijn identiek!

Overal werd het bestandssysteem xfs gebruikt.

Ik vergeleek het met het commando

docker inspect my-nginx:12345

Alle hashes zijn identiek, allemaal precies hetzelfde. Zowel op de server als op mijn virtuele machine. Ik verwijderde het lokale nginx-image en haalde het opnieuw van de registry, die om verschillende redenen op dezelfde machine staat. En het probleem is hetzelfde… Nu trilt ook mijn andere oog.

Ik kan me niet herinneren welke gedachten er in mijn hoofd waren, naast schreeuwen 'AAAAAAA' en dergelijke. Het is 4 uur 's nachts, de bronbestanden van Docker zijn in gebruik om het principe van hashing van de layers van het image te begrijpen. Ik heb het derde blik energiedrank geopend. En uiteindelijk realiseerde ik me dat hashing alleen het bestand en de inhoud ervan in overweging neemt, maar GEEN TOEGANGSRIGHTS! Dus op een of andere mysterieuze manier zijn onze rechten verstoord, terwijl selinux uitgeschakeld is, acl niet wordt gebruikt, en de sticky bit ontbreekt.

Ik verwijderde het lokale image, verwijderde ook het image van de docker registry en duwde het opnieuw. En alles werkte. Het blijkt dat de rechten zijn verstoord tijdens de overdracht, zowel binnen het lokale image als binnen het image in de registry. Zoals ik al zei, bevond deze zich om verschillende redenen op dezelfde machine. En als gevolg in dezelfde map /var/lib/docker.

En in afwachting van de vraag of we geprobeerd hebben om Docker naar de oude map te verwijzen — nee, we hebben het niet geprobeerd, helaas, de omstandigheden lieten het niet toe. En ik wilde het graag uitzoeken.

Na het schrijven van dit artikel lijkt de oplossing voor het probleem me vanzelfsprekend, maar op het moment van het analyseren leek het niet zo. Ik heb eerlijk gegoogeld en vond geen vergelijkbare situaties.

Conclusie: probleem opgelost, maar de oorzaak begreep ik niet =(

Als iemand ideeën heeft of een idee heeft over de mogelijke oorzaken van dit probleem — ik hoor het graag in de reacties!

Bron: habr.com