Varför ansluter en Compose-stack en ny tom namngiven volym efter omdistribution?
En Compose-stack kan ansluta en ny tom namngiven volym när omdistributionen ändrar det projektspecifika volymnamnet eller inte hittar den ursprungliga volymen.
De gamla data kan fortfarande finnas i en annan Docker-volym, medan den återskapade tjänsten monterar en nygenererad volym på samma sökväg i containern. Vanliga orsaker är ett ändrat stack- eller projektnamn, en omdöpt volymnyckel, borttagning med ett kommando som raderar volymer, en borttagen extern deklaration, distribution via en annan hanterare eller ett explicit volymnamn som nu tolkas annorlunda. Inventera både den monterade volymen och övergivna kandidater innan du återställer data eller initierar appen.
Identifiera den exakta volym som den nya containern monterar
Inspektera den körande containerns monteringar och notera volymnamn, drivrutin, monteringspunkt, etiketter, skapandetid, containerns målsökväg och läs- och skrivläge. Jämför dem med poster från före omdistributionen.
Ubuntus docker volume inspect-kommando visar volymens identitet, vilket gör det möjligt att skilja den nya tomma volymen från en äldre avmonterad volym med liknande namn.
Kopiera inte data till den nya volymen innan originalet har hittats. Om du startar appen kan den skapa en ny databas och få målet att se ut som om det redan har initierats avsiktligt.
Kontrollera om Compose-projektnamnet har ändrats
Jämför det gamla och nya projektnamnet, stacknamnet, Compose-katalogen, alternativet -p, COMPOSE_PROJECT_NAME, toppnivåfältet name: och distributionshanteraren.
Docker förklarar att Compose normalt omfattar en volym med projektnamn plus volymnyckel, om inte ett explicit namn eller en sökning efter en extern volym har konfigurerats.
Om samma Compose-fil flyttas till en annan katalog kan det därför skapa ett andra projekt och en andra volym, även när tjänste- och volymnycklarna är oförändrade.
Verifiera inställningar för stabilt namn och extern volym
Jämför definitionen på toppnivå för volymen före och efter omdistributionen. Kontrollera name:, external:, drivrutinsalternativ, interpoleringsvariabler och om den förväntade volymen finns.
Microsofts Docker Compose-guide noterar att namngivna volymer finns kvar oberoende av om containrar ersätts, så ett nytt tomt tillstånd innebär vanligtvis att en annan volymidentitet anslöts eller att den gamla volymen togs bort.
Markera en volym som extern endast när dess livscykel avsiktligt hanteras utanför stacken. Compose bör tydligt misslyckas när en extern volym saknas, i stället för att tyst skapa en ersättning.
Kontrollera om en rensning tog bort originalvolymen
Granska distributionsloggar, skript, åtgärder i gränssnittet, rensningsjobb och kommandon som tar bort volymer. Jämför volymens skapandetid med händelsen för omdistribution.
Red Hat dokumenterar att namngivna volymer som hanteras av containrar har separata lagringsplatser från containrarnas skrivbara lager, vilket är anledningen till att borttagning av en container och borttagning av dess namngivna volym är olika livscykelhändelser.
Om originalvolymen saknas ska du stoppa automatiska starter och endast återställa från en verifierad säkerhetskopia. Anta inte att en tom ersättningsvolym innehåller ett återställningsbart borttaget lager.
Jämför stackhanterarens identitet och distributionsmetod
Notera om stacken startades via CLI, Portainer, en appbutik för NAS, en Git-distribution eller ett annat automatiseringsverktyg. Jämför stacknamnet och miljövärdena som hanteraren lagrar.
Portainer kräver ett beskrivande stacknamn vid distribution, och den hanterarstyrda identiteten kan skilja sig från det katalogbaserade projektnamn som används av ett manuellt Compose-kommando.
En manuell nödstarter kan därför skapa resurser under ett annat projekprefix. Välj en enda distributionsansvarig och dokumentera de upplösta volymnamn som den skapar.
Uteslut att data döljs under den nya volymmonteringen
Stoppa containern och inspektera avbildningen eller bind-sökvägen utan den namngivna volymen monterad, i ett tillfälligt test. Ta reda på om starten skrev data till containerlagret innan volymen monterades.
Linux-handboken för montering förklarar att en montering döljer befintligt innehåll i katalogen, så data kan verka saknas när en ny tom volym täcker filer som skapats i avbildningen eller det skrivbara lagret.
Slå inte ihop det dolda lagret och den gamla beständiga volymen utan eftertanke. Fastställ vilket tillstånd som är det auktoritativa och använd appens stödda återställningsmetod.
Anslut originalvolymen igen med ett kontrollerat test
Stoppa stacken, säkerhetskopiera båda kandidatvolymerna, anslut originalet till en tillfällig container eller tjänstesökväg och verifiera appfiler, databasidentitet, ägarskap och tidsstämplar.
ZimaSpaces guide om att flytta containerdata utan att bryta monteringar beskriver ett närliggande arbetsflöde för sökvägsmappning; den här artikeln fokuserar på identiteten hos projektspecifika namngivna volymer.
Problemet är löst när den avsedda gamla volymen monteras under ett stabilt explicit eller externt namn och upprepade omdistributioner återanvänder den utan att skapa ännu en tom kandidat.
Vanliga frågor
Innebär en tom namngiven volym att de gamla data har raderats?
Inte nödvändigtvis. Den gamla volymen kan fortfarande finnas under ett annat projekprefix eller explicit namn, medan den nya containern använder en annan tom volym.
Kan ett ändrat namn på Compose-katalogen skapa en ny volym?
Ja. När inget projektnamn har fastställts kan Compose härleda det från projektkatalogen och skapa resurser med andra prefix.
Bör viktiga volymer markeras som externa?
Externa volymer kan förhindra att stackborttagning hanterar deras livscykel, men de kräver medveten skapelse, namngivning, säkerhetskopiering och kontroller vid distribution.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
