Historie om migreringsproblemet for docker-lagring (docker-rot)

For ikke mer enn et par dager siden ble det besluttet på en av serverne å flytte docker-lagring (katalogen der docker lagrer alle container- og bildefiler) til en egen seksjon, som
hadde større kapasitet. Oppgaven virket triviell og forutsa ikke problemer...

La oss komme i gang:

1. Stopp og drep alle beholderne i applikasjonen vår:

docker-compose down

hvis det er mange beholdere og de er i forskjellige sammensetninger, kan du gjøre dette:

docker rm -f $(docker ps -q)

2. Stopp docker-demonen:

systemctl stop docker

3. Flytt katalogen til ønsket plassering:

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

4. Vi ber docker-demonen se i den nye katalogen. Det er flere alternativer: enten bruk -g-flagget for å peke demonen til en ny bane, eller systemd-konfigurasjoner, som vi brukte. Eller en symbolkobling. Jeg skal ikke gå for mye i detalj om dette, det er på Internett. full håndbøker for å flytte docker-roten til et nytt sted.

5. Start docker-demonen og sørg for at den ser ut på riktig sted:

systemctl status docker

I en av utgangslinjene bør vi se:

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

Vi sørget for at alternativet ble sendt til demonen, la oss nå sjekke om det brukte det (takk inkvisitor68sl)!

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

6. La oss starte søknaden vår:

docker-compose up -d

7. Kontroll

Og her begynner moroa, DBMS, MQ, alt er bra! Databasen er intakt, alt fungerer... bortsett fra nginx. Vi har vårt eget nginx-bygg med Kerberos og kurtisaner. Og visning av beholderloggene indikerte at den ikke kan skrive til /var/tmp - Tillatelse nektet. Jeg elter tinningene med fingrene og prøver å analysere situasjonen... Hvordan er dette mulig? Docker-bildet endret seg ikke. Vi har nettopp flyttet katalogen. Det fungerte alltid, og her er det for deg... For eksperimentets skyld gikk jeg inn i beholderen med hendene og endret rettighetene til denne katalogen, det var rot, rot 755, ga rot, rot 777. Og alt begynte... En tanke begynte å lyde i hodet mitt - noe slags tull... Jeg tenkte, vel, kanskje jeg ikke tok hensyn til noe...

Jeg bestemte meg for at vi ble forelsket i tilgangsrettighetene til filene under overføringen. Vi stoppet applikasjonen, docker-daemonen, slettet den nye katalogen og kopierte /var/lib/docker-katalogen med rsync -a.

Jeg tror alt er bra nå, la oss heve Docker-applikasjonen.

Aaand... problemet gjensto... Øyet mitt rykket. Jeg skyndte meg til konsollen på den virtuelle maskinen min, hvor jeg kjører forskjellige tester, jeg hadde dette nginx-bildet, og jeg klatret inn i beholderen, og her er rettighetene til /var/tmp-katalogen root, root 777. Det vil si at samme som jeg måtte stille inn manuelt. Men bildene er identiske!

xfs-filsystemet ble brukt overalt.

Jeg sammenlignet med kommandoen

docker inspect my-nginx:12345

Alle hash er identiske, alle én til én. Både på serveren og på min virtuelle maskin. Jeg slettet det lokale nginx-bildet og trakk det igjen fra registeret, som av flere grunner er på samme maskin. Og problemet er det samme... Nå rykker det andre øyet mitt.

Jeg husker ikke lenger hvilke tanker som var i hodet mitt, foruten å rope "AAAAAAAAAA" og andre ting. Klokken var fire om morgenen, og Docker-kildekoden ble brukt for å forstå prinsippet om hashing av bildelag. Åpnet den tredje boksen med energidrikk. Og til slutt gikk det opp for meg at hashing bare tar hensyn til filen, dens innhold, men IKKE TILGANGSRETTIGHETER! Det vil si at rettighetene våre har gått tapt på en mystisk måte, selinux er deaktivert, acl brukes ikke, og det er ingen sticky bit.

Jeg slettet det lokale bildet, slettet også bildet fra docker-registeret og presset det igjen. Og alt fungerte. Det viser seg at under overføringen gikk rettighetene tapt, både inne i det lokale bildet og inne i bildet som ligger i registeret. Som jeg allerede sa, var den av flere grunner plassert på samme bil. Og som et resultat, i en katalog /var/lib/docker.

Og å forutse spørsmålet om de prøvde å returnere havnearbeiderens blikk til den gamle katalogen - nei, de prøvde ikke, dessverre, omstendighetene tillot det ikke. Ja, og jeg ville virkelig finne ut av det.

Etter å ha skrevet denne artikkelen virker løsningen på problemet åpenbar for meg, men på analysetidspunktet virket det ikke slik. Ærlig talt, jeg googlet og fant ikke lignende situasjoner.

Resultat: Jeg løste problemet, jeg forstår fortsatt ikke grunnen =(

Hvis noen vet, gjetter, hadde en visjon om mulige årsaker til dette problemet, vil jeg være ekstremt glad for å høre fra deg i kommentarene!

Kilde: www.habr.com