Geschiedenis van het docker-opslagmigratieprobleem (docker root)

Nog niet meer dan een paar dagen geleden werd op een van de servers besloten om de docker-opslag (de map waar docker alle container- en afbeeldingsbestanden opslaat) te verplaatsen naar een aparte sectie, die
grotere capaciteit hadden. De taak leek triviaal en voorspelde geen problemen...

Laten we beginnen:

1. Stop en dood alle containers van onze applicatie:

docker-compose down

als er veel containers zijn en deze in verschillende samenstellingen zijn, kunt u dit doen:

docker rm -f $(docker ps -q)

2. Stop de docker-daemon:

systemctl stop docker

3. Verplaats de map naar de gewenste locatie:

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

4. We vertellen de docker-daemon om in de nieuwe map te kijken. Er zijn verschillende opties: gebruik de vlag -g om de daemon naar een nieuw pad te verwijzen, of systemd configs, die we hebben gebruikt. Of een symlink. Ik zal hier niet te veel op ingaan, het staat op internet. vol handleidingen over het verplaatsen van docker root naar een nieuwe locatie.

5. Start de docker-daemon en zorg ervoor dat deze op de juiste plaats staat:

systemctl status docker

In een van de uitvoerregels zouden we het volgende moeten zien:

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

We hebben ervoor gezorgd dat de optie is doorgegeven aan de daemon. Laten we nu controleren of deze is toegepast (bedankt inktvizitor68sl)!

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

6. Laten we onze applicatie starten:

docker-compose up -d

7. Controleren

En hier begint het plezier, DBMS, MQ, alles is in orde! De database is intact, alles werkt... behalve nginx. We hebben onze eigen nginx gebouwd met Kerberos en courtisanes. En het bekijken van de containerlogboeken gaf aan dat er niet naar /var/tmp kan worden geschreven - Toestemming geweigerd. Ik kneed mijn slapen met mijn vingers en probeer de situatie te analyseren... Hoe is dit mogelijk? De Docker-image is niet gewijzigd. We hebben zojuist de map verplaatst. Het heeft altijd gewerkt, en hier is het voor jou... Ter wille van het experiment ging ik met mijn handen de container in en veranderde de rechten op deze map, er waren wortel, wortel 755, gaf wortel, wortel 777. En alles begon... Er begon een gedachte in mijn hoofd te klinken - een soort onzin... Ik dacht: nou ja, misschien heb ik ergens geen rekening mee gehouden...

Ik besloot dat we tijdens de overdracht verliefd werden op de toegangsrechten tot de bestanden. We stopten de applicatie, de docker-daemon, verwijderden de nieuwe map en kopieerden de map /var/lib/docker met behulp van rsync -a.

Ik denk dat alles nu in orde is, laten we de Docker-applicatie verhogen.

En... het probleem bleef... Mijn oog trilde. Ik snelde naar de console van mijn virtuele machine, waar ik verschillende tests uitvoerde, ik had deze nginx-image en ik klom in de container, en hier zijn de rechten op de map /var/tmp root, root 777. Dat wil zeggen, de hetzelfde als ik handmatig moest instellen. Maar de afbeeldingen zijn identiek!

Het xfs-bestandssysteem werd overal gebruikt.

Ik heb vergeleken met behulp van het commando

docker inspect my-nginx:12345

Alle hashes zijn identiek, allemaal één op één. Zowel op de server als op mijn virtuele machine. Ik heb de lokale nginx-image verwijderd en opnieuw uit het register gehaald, dat om een ​​aantal redenen op dezelfde machine staat. En het probleem is hetzelfde... Nu trilt mijn tweede oog.

Ik herinner me niet meer welke gedachten er in mijn hoofd zaten, afgezien van het roepen van “AAAAAAAAA” en andere dingen. Het was 4 uur in de ochtend en de Docker-broncode werd gebruikt om het principe van het hashen van afbeeldingslagen te begrijpen. Het derde blikje energiedrank geopend. En uiteindelijk drong het tot me door dat hashen alleen rekening houdt met het bestand en de inhoud ervan, maar GEEN TOEGANGSRECHTEN! Dat wil zeggen, op een of andere mysterieuze manier zijn onze rechten verloren gegaan, is selinux uitgeschakeld, wordt acl niet gebruikt en is er geen sticky bit.

Ik heb de lokale afbeelding verwijderd, ook de afbeelding uit het docker-register verwijderd en opnieuw gepusht. En alles werkte. Het blijkt dat tijdens de overdracht de rechten verloren zijn gegaan, zowel binnen de lokale afbeelding als binnen de afbeelding die in het register ligt. Zoals ik al zei, bevond hij zich om een ​​aantal redenen op dezelfde auto. En als gevolg daarvan in één map /var/lib/docker.

En vooruitlopend op de vraag of ze probeerden de blik van de havenarbeider terug te brengen naar de oude directory - nee, ze probeerden het niet, helaas lieten de omstandigheden het niet toe. Ja, en ik wilde het echt uitzoeken.

Na het schrijven van dit artikel lijkt de oplossing voor het probleem mij voor de hand liggend, maar op het moment van analyse leek dat niet zo. Eerlijk gezegd heb ik gegoogled en heb ik geen soortgelijke situaties gevonden.

Resultaat: ik heb het probleem opgelost, ik begrijp de reden nog steeds niet =(

Als iemand het weet, vermoedt, een visie heeft over de mogelijke oorzaken van dit probleem, zal ik heel blij zijn om van je te horen in de reacties!

Bron: www.habr.com