Historik om migreringsproblemet för docker-lagring (docker-rot)

För inte mer än ett par dagar sedan beslutades det på en av servrarna att flytta docker storage (katalogen där docker lagrar alla container- och bildfiler) till en separat sektion, vilket
hade större kapacitet. Uppgiften verkade trivial och förutsade inga problem...

Låt oss börja:

1. Stoppa och döda alla behållare i vår applikation:

docker-compose down

om det finns många behållare och de är i olika sammansättningar kan du 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. Vi ber docker-demonen att leta i den nya katalogen. Det finns flera alternativ: antingen använd flaggan -g för att peka demonen till en ny sökväg, eller systemd-konfigurationer, som vi använde. Eller en symbollänk. Jag ska inte gå in för mycket i detalj om detta, det finns på Internet. full manualer om att flytta docker root till en ny plats.

5. Starta docker-demonen och se till att den ser ut på rätt plats:

systemctl status docker

I en av utgångslinjerna bör vi se:

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

Vi såg till att alternativet skickades till demonen, låt oss nu kontrollera om det tillämpade det (tack inkvisitor68sl)!

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

6. Låt oss börja vår ansökan:

docker-compose up -d

7. Kontrollera

Och här börjar det roliga, DBMS, MQ, allt är bra! Databasen är intakt, allt fungerar... utom nginx. Vi har vårt eget nginx-bygge med Kerberos och kurtisaner. Och att titta på behållarloggarna indikerade att den inte kan skriva till /var/tmp - Permission nekad. Jag knådar mina tinningar med fingrarna och försöker analysera situationen... Hur är detta möjligt? Docker-bilden ändrades inte. Vi har precis flyttat katalogen. Det fungerade alltid, och här är det för dig... För experimentets skull gick jag in i behållaren med mina händer och ändrade rättigheterna till den här katalogen, det fanns rot, rot 755, gav rot, rot 777. Och allt började... En tanke började ljuda i mitt huvud - något slags nonsens... Jag tänkte, ja, jag kanske inte tog hänsyn till något...

Jag bestämde mig för att vi blev kära i åtkomsträttigheterna till filerna under överföringen. Vi stoppade programmet, docker-demonen, tog bort den nya katalogen och kopierade /var/lib/docker-katalogen med rsync -a.

Jag tror att allt är bra nu, låt oss höja Docker-applikationen.

Aaand... problemet kvarstod... Jag ryckte i ögat. Jag rusade till konsolen på min virtuella maskin, där jag kör olika tester, jag hade den här nginx-bilden, och jag klättrade in i behållaren, och här är rättigheterna till katalogen /var/tmp root, root 777. Det vill säga samma som jag var tvungen att ställa in manuellt. Men bilderna är identiska!

Filsystemet xfs användes överallt.

Jag jämförde med kommandot

docker inspect my-nginx:12345

Alla hash är identiska, alla en till en. Både på servern och på min virtuella maskin. Jag tog bort den lokala nginx-bilden och drog den igen från registret, som av flera anledningar finns på samma maskin. Och problemet är detsamma... Nu rycker det i mitt andra öga.

Jag minns inte längre vilka tankar som fanns i mitt huvud, förutom att ropa "AAAAAAAAAA" och annat. Klockan var fyra på morgonen och Docker-källkoden användes för att förstå principen för att hasha bildlager. Öppnade den tredje burken energidryck. Och till slut gick det upp för mig att hashing bara tar hänsyn till filen, dess innehåll, men INTE TILLGÅNGSRÄTT! Det vill säga, på något mystiskt sätt har våra rättigheter gått förlorade, selinux är inaktiverat, acl används inte och det finns ingen sticky bit.

Jag tog bort den lokala bilden, tog också bort bilden från docker-registret och tryckte på den igen. Och allt fungerade. Det visar sig att under överlåtelsen gick rättigheterna förlorade, både inuti den lokala bilden och inuti bilden som ligger i registret. Som jag redan sa, av ett antal anledningar var den placerad på samma bil. Och som ett resultat, i en katalog /var/lib/docker.

Och att förutse frågan om de försökte återvända hamnarbetarens blick till den gamla katalogen - nej, de försökte inte, tyvärr, omständigheterna tillät det inte. Ja, och jag ville verkligen ta reda på det.

Efter att ha skrivit den här artikeln verkar lösningen på problemet uppenbar för mig, men vid analystillfället verkade det inte så. Ärligt talat, jag googlade och hittade inte liknande situationer.

Resultat: Jag löste problemet, jag förstår fortfarande inte orsaken =(

Om någon vet, gissningar, hade en vision om de möjliga orsakerna till detta problem, kommer jag att vara oerhört glad att höra från dig i kommentarerna!

Källa: will.com