Varför använder en Compose-tjänst fel .env-fil först efter en omstart av värddatorn?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Why Does a Compose Service Use the Wrong Env File Only After a Host Reboot?

En Compose-tjänst kan använda andra miljövärden efter en omstart när startprogrammet vid uppstart hittar en annan projektkatalog, env-fil eller prioritetskälla.

Ett manuellt kommando kan köras från den avsedda mappen med en viss skalmiljö, medan systemd, en NAS-schemaläggare eller Portainer startar samma Compose-fil från ett annat sammanhang efter uppstart. Tjänsten kan också starta om en befintlig container vars miljö fastställdes när den skapades, i stället för att läsa in den redigerade filen igen. Jämför den renderade Compose-modellen och miljön för den körande processen från de manuella start- och uppstartsvägarna innan du redigerar flera filer samtidigt.

Jämför den körande miljön med den avsedda filen

Anteckna containerns ID, skapandetid, avbildning, Compose-etiketter, projektnamn och de faktiska värden som är synliga i huvudprocessen. Jämför dem med den avsedda env-filen utan att skriva ut hemligheter i delade loggar.

Linux processmiljö visar värdena som tillhandahölls vid körningen, vilket är starkare bevis än att läsa en env-fil som den aktuella containern kanske aldrig har använt.

Om containern innehåller de gamla värdena och skapades före distributionen vid omstarten, kan tjänsten bara ha startat om den. Om containern är ny, fortsätt med prioritet och sökvägsupplösning.

Tillämpa Compose-prioritet för miljövariabler i rätt ordning

Lista alla källor för en ofarlig variabel: CLI-flaggor, skalvärden, environment:, env_file:, standardfilen eller den uttryckliga .env-filen samt avbildningens ENV.

Docker definierar en formell prioritetsordning för miljövariabler, så en korrekt env-fil kan ändå åsidosättas av ett värde med högre prioritet som injiceras av uppstartstjänsten eller stackhanteraren.

Sök inte bara efter duplicerade filnamn. Sök efter variabelnamnet i den renderade Compose-modellen, unit-filen, hanterarens inställningar, skalets miljö och avbildningens standardvärden.

Kontrollera projektkatalogen och relativa env-sökvägar

Jämför arbetskatalogen för det manuella kommandot med uppstartsprogrammets arbetskatalog, argumenten för Compose-filen, projektkatalogen och relativa referenser till env_file.

Compose-specifikationen definierar den applikationsmodell som används för att lösa tjänster och konfiguration, så den valda projektdefinitionen och dess sökvägar är indata till distributionen och inte egenskaper som återskapas från den körande containern.

Använd absoluta sökvägar för env-filer som är kritiska vid uppstart när distributionsverktyget stöder det, eller ange en explicit projektkatalog och arbetskatalog så att manuella och automatiska starter hittar samma filer.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Inspektera systemds arbetskatalog och miljöfiler

Läs den aktiva uniten, alla drop-in-filer, WorkingDirectory=, Environment=, EnvironmentFile= och ExecStart=. Jämför uniten som läses in vid uppstart med kommandot som används manuellt.

Systemds körningsinställningar definierar tjänstens arbetskatalog och miljöfiler, vilka inte automatiskt ärver en interaktiv inloggningsskals aktuella katalog eller exporterade variabler.

Efter att du har ändrat en unit eller drop-in ska du läsa in systemd-hanteraren igen och inspektera den aktiva uniten på nytt. Att redigera en mall eller en oanvänd fil ändrar inte tjänsten som faktiskt startas.

Kontrollera stackhanterarens variabler och sparade distributionsstatus

Om Portainer eller ett NAS-gränssnitt äger stacken ska du jämföra dess sparade variabler, uppladdade env-fil, Git-distributionssökväg, webhook-beteende vid uppdateringar och den visade Compose-modellen.

Portainer skiljer mellan beteendet för .env och stack.env, så värden som anges i hanteraren kan skilja sig från en fil som redigeras direkt på värden.

Välj en enda källa som gäller. En stack som hanteras från Git eller en webbredigerare bör inte dessutom startas manuellt från en annan lokal kopia efter varje omstart.

Återskapa containern i stället för att bara starta om den

Jämför containerns skapandetid med tiden då env-filen redigerades. Rendera den avsedda Compose-konfigurationen och återskapa sedan endast den berörda tjänsten på ett kontrollerat sätt.

RHEL:s systemd-vägledning rekommenderar att du kontrollerar filerna och åsidosättningarna som faktiskt används av en tjänst innan du startar om den. Då undviker du att en föråldrad unit eller wrapper återskapar containern med gamla värden.

En omstart av en container återskapar inte dess miljö från Compose. Återskapa den först efter att du har skyddat beständiga data och bekräftat att den renderade modellen pekar på avsedda volymer och hemligheter.

Se till att manuell start, omstart och omdistribution ger samma modell

Fastställ Compose-filerna, projektnamnet, projektkatalogen, sökvägen till env-filen, stackägaren och uppstartsberoendet. Spara en redigerad, avidentifierad konfiguration och ett ofarligt miljöfingeravtryck.

ZimaSpace-artikeln om omfattningen av Docker-säkerhetskopiering beskriver den närliggande regeln: miljöfiler och distributionsdefinitioner måste bevaras tillsammans med beständiga data.

Problemet är löst när en manuell återskapning, en omstart av värddatorn, en schemalagd uppdatering och en omdistribution från stackhanteraren alla skapar tjänsten med samma avidentifierade miljöfingeravtryck.

Vanliga frågor

Vad är skillnaden mellan .env och env_file?

En projektfil med namnet .env tillhandahåller vanligtvis interpoleringsvärden till Compose, medan en env_file för en tjänst tillhandahåller variabler till containern. Hur de samverkar och prioriteras beror på den fullständiga Compose-modellen.

Laddar en omstart av en container in en ändrad env-fil?

Nej. Miljövärden anges när containern skapas. Tjänsten måste normalt återskapas från den korrigerade Compose-konfigurationen.

Varför uppstår problemet bara efter en omstart?

Omstartsvägen kan använda en systemd-unit, en schemaläggare, variabler som sparats av en hanterare, en annan arbetskatalog eller en äldre Compose-kopia som skiljer sig från den manuella starten.