Historien om problemet med att flytta dockerstorage (docker root)

Inte längre än för ett par dagar sedan beslutades det att flytta dockerlagret (katalogen där docker lagrar alla containrar och bilder) till en separat partition som
hade större kapacitet. Uppgiften verkade vara trivial och förutsatte inga problem...

Låt oss börja:

1. Stoppa och döda alla containrar av vår applikation:

docker-compose down

om det finns många containrar och de är i olika compose-filer kan vi göra så här:

docker rm -f $(docker ps -q)

2. Stoppa docker-demonen:

systemctl stop docker

3. Flytta katalogen till önskad plats:

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

4. Berätta för docker-demonen att den ska titta i den nya katalogen. Här finns flera alternativ: antingen ange den nya sökvägen via flaggan -g, eller använda systemd-konfigurationerna, som vi använde. Eller så kan man skapa en symlink. Jag kommer inte att gå in på detaljer här, det finns massor av manualer på internet om att flytta docker root till en ny plats.

5. Starta docker-demonen och kontrollera att den pekar åt rätt håll:

systemctl status docker

I en av raderna i utskriften borde vi se:

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

Vi bekräftade att vi skickade alternativet till demon, nu ska vi kontrollera om den tillämpade det (tack inkvizitor68sl)!

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

6. Starta vår applikation:

docker-compose up -d

7. Kontrollera

Och här börjar det intressanta, databasen, MQ, allt fungerar! Databasen är intakt, allt fungerar... förutom nginx. Vi har vår egen version av nginx med Kerberos och kurviga slutsatser. Och visning av loggar från containern visade att den inte kunde skriva till /var/tmp - Åtkomst nekad. Jag masserar mina tinningar och försöker analysera situationen... Hur kunde det bli så? Dockerimagen ändrades ju inte. Vi flyttade bara katalogen. Det har alltid fungerat, och plötsligt... För experimentets skull gick jag in i containern och ändrade rättigheterna för denna katalog, det varroot, root 755 , gavroot, root 777

. Och allt började fungera... En tanke slog mig - vilken absurditet... Jag tänkte, kanske jag missade något... Jag bestämde mig för att vi missade filrättigheterna vid överföringen. Vi stoppade applikationen, docker-demonen, tog bort den nya katalogen och kopierade katalogen /var/lib/docker genom att använda.

rsync -a. Jag tror, nu ska allt vara bra, vi startar docker, applikationen.

Och… problemet kvarstår… Jag har fått ett ryck i ögat. Jag skyndade mig till konsolen för min virtuella maskin där jag kör olika tester. Jag hade denna nginx-avbild och gick in i containern, och här i katalogen /var/tmp är rättigheterna satta till root, root 777. Sådana som jag var tvungen att sätta manuellt. Men avbildarna är identiska!

XFS-filsystemet användes överallt.

Jag jämförde med kommandot

docker inspect my-nginx:12345

Alla hashvärden är identiska, alla är en och samma. Både på servern och på min virtuella maskin. Jag raderade den lokala nginx-avbilden och drog ner den igen från registry som av olika anledningar ligger på samma maskin. Och problemet kvarstår… Nu har mitt andra öga fått ett ryck.

Jag minns inte vilka tankar som fanns i mitt huvud förutom skrik av "AAAAAA" och liknande. Klockan är fyra på morgonen, jag började titta på dockerkällkoden för att förstå hur hashning av bildlager fungerar. Jag öppnade en tredje burk energidryck. Och till slut insåg jag att hashningen endast tar hänsyn till filen och dess innehåll, men INGEN ÅTKOMSTRÄTT! Alltså, på något mystiskt sätt har rättigheterna blivit felaktiga, trots att selinux är avstängt, acl inte används och sticky bit inte är aktiv.

Jag raderade den lokala avbilden, raderade också avbilden från docker registry och pushade upp den igen. Och allt fungerade. Det visar sig att rättigheterna blev felaktiga både i den lokala avbilden och i avbilden i registry. Som jag nämnde tidigare låg den av flera skäl på samma maskin. Och som en följd i katalogen /var/lib/docker.

Och för att förutse frågan om vi försökte återföra docker blicken på den gamla katalogen — nej, vi försökte inte, tyvärr, omständigheterna tillät inte det. Dessutom ville jag verkligen förstå.

Efter att ha skrivit denna artikel verkar lösningen på problemet uppenbar för mig, men vid tidpunkten för analys verkade den inte så. Jag googlade ärligt och hittade inga liknande situationer.

Resultatet: jag löste problemet, men förstod inte orsaken =(

Om någon har idéer om möjliga orsaker till detta problem — jag skulle vara mycket tacksam för era kommentarer!

Källa: habr.com