Historien om migreringsproblemet med docker-lager (docker-rod)

For ikke mere end et par dage siden blev det besluttet på en af ​​serverne at flytte docker storage (biblioteket hvor docker gemmer alle container- og billedfiler) til en separat sektion, som
havde større kapacitet. Opgaven virkede triviel og forudsagde ikke problemer...

Lad os komme igang:

1. Stop og dræb alle beholdere i vores applikation:

docker-compose down

hvis der er mange beholdere, og de er i forskellige sammensætninger, kan du gøre dette:

docker rm -f $(docker ps -q)

2. Stop docker-dæmonen:

systemctl stop docker

3. Flyt mappen til den ønskede placering:

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

4. Vi beder docker-dæmonen om at kigge i den nye mappe. Der er flere muligheder: enten brug -g flaget til at pege dæmonen til en ny sti, eller systemd configs, som vi brugte. Eller et symbollink. Jeg vil ikke gå for meget i detaljer om dette, det er på internettet. fuld manualer om flytning af docker-rod til en ny placering.

5. Start docker-dæmonen, og sørg for, at den ser ud på det rigtige sted:

systemctl status docker

I en af ​​outputlinjerne skulle vi se:

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

Vi sørgede for, at indstillingen blev videregivet til dæmonen, lad os nu kontrollere, om den anvendte den (tak inkvisitor68sl)!

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

6. Lad os starte vores ansøgning:

docker-compose up -d

7. Kontrol

Og her begynder det sjove, DBMS, MQ, alt er fint! Databasen er intakt, alt virker... undtagen nginx. Vi har vores egen nginx build med Kerberos og kurtisaner. Og visning af containerlogfilerne indikerede, at den ikke kan skrive til /var/tmp - Tilladelse nægtet. Jeg ælter mine tindinger med fingrene og prøver at analysere situationen... Hvordan er det muligt? Docker-billedet ændrede sig ikke. Vi har lige flyttet mappen. Det virkede altid, og her er det til dig... For eksperimentets skyld gik jeg ind i containeren med mine hænder og ændrede rettighederne til denne mappe, der var rod, rod 755, gav rod, rod 777. Og alting startede... En tanke begyndte at lyde i mit hoved - en slags vrøvl... Jeg tænkte, ja, måske tog jeg ikke hensyn til noget...

Jeg besluttede, at vi blev forelsket i adgangsrettighederne til filerne under overførslen. Vi stoppede applikationen, docker-dæmonen, slettede den nye mappe og kopierede /var/lib/docker-mappen vha. rsync -a.

Jeg tror, ​​at alt er i orden nu, lad os hæve Docker-applikationen.

Aaand... problemet forblev... Mit øje rykkede. Jeg skyndte mig til konsollen på min virtuelle maskine, hvor jeg kører forskellige tests, jeg havde dette nginx-billede, og jeg klatrede ind i containeren, og her er rettighederne til mappen /var/tmp root, root 777. Det vil sige, samme som jeg skulle indstille manuelt. Men billederne er identiske!

xfs-filsystemet blev brugt overalt.

Jeg sammenlignede med kommandoen

docker inspect my-nginx:12345

Alle hashes er identiske, alle én til én. Både på serveren og på min virtuelle maskine. Jeg slettede det lokale nginx-billede og trak det igen fra registreringsdatabasen, som af en række årsager er på den samme maskine. Og problemet er det samme... Nu rykker mit andet øje.

Jeg husker ikke længere, hvilke tanker der var i mit hoved, udover at råbe "AAAAAAAAAA" og andre ting. Klokken var 4 om morgenen, og Docker-kildekoden blev brugt til at forstå princippet om hashing af billedlag. Åbnede den tredje dåse energidrik. Og til sidst gik det op for mig, at hashing kun tager hensyn til filen, dens indhold, men IKKE ADGANGSRET! Det vil sige, på en mystisk måde er vores rettigheder gået tabt, selinux er deaktiveret, acl bruges ikke, og der er ingen sticky bit.

Jeg slettede det lokale billede, slettede også billedet fra docker-registret og skubbede det igen. Og alt fungerede. Det viser sig, at under overførslen gik rettighederne tabt, både inde i det lokale billede og inde i billedet, der ligger i registret. Som jeg allerede sagde, var den af ​​flere årsager placeret på den samme bil. Og som et resultat, i en mappe /var/lib/docker.

Og foregribe spørgsmålet, om de forsøgte at vende havnearbejderens blik tilbage til den gamle mappe - nej, de prøvede ikke, desværre, omstændighederne tillod det ikke. Ja, og jeg ville virkelig finde ud af det.

Efter at have skrevet denne artikel virker løsningen på problemet indlysende for mig, men på analysetidspunktet virkede det ikke sådan. Helt ærligt, jeg Googlede og fandt ikke lignende situationer.

Resultat: Jeg løste problemet, jeg forstår stadig ikke årsagen =(

Hvis nogen ved, gætter, havde en vision om de mulige årsager til dette problem, vil jeg være meget glad for at høre fra dig i kommentarerne!

Kilde: www.habr.com