Waarom gebruikt een Compose-service pas na een herstart van de host het verkeerde env-bestand?
Een Compose-service kan na een herstart andere omgevingswaarden gebruiken wanneer de launcher tijdens het opstarten een andere projectmap, een ander env-bestand of een andere bron met voorrang gebruikt.
Een handmatige opdracht kan vanuit de bedoelde map met één shellomgeving worden uitgevoerd, terwijl systemd, een NAS-planner of Portainer hetzelfde Compose-bestand na het opstarten vanuit een andere context start. De service kan ook een bestaande container herstarten waarvan de omgeving bij het aanmaken is vastgelegd, in plaats van het bewerkte bestand opnieuw in te lezen. Vergelijk het gegenereerde Compose-model en de omgeving van het actieve proces vanuit zowel het handmatige als het opstartpad voordat je meerdere bestanden tegelijk bewerkt.
Vergelijk de actieve omgeving met het bedoelde bestand
Noteer de container-ID, aanmaaktijd, image, Compose-labels, projectnaam en de werkelijke waarden die zichtbaar zijn in het hoofdproces. Vergelijk deze met het bedoelde env-bestand zonder geheimen in gedeelde logboeken af te drukken.
De procesomgeving van Linux toont de waarden die tijdens de uitvoering zijn aangeleverd, wat sterker bewijs is dan het lezen van een env-bestand dat de huidige container mogelijk nooit heeft gebruikt.
Als de container de oude waarden bevat en ouder is dan de implementatie tijdens het opstarten, is de service mogelijk alleen herstart. Als de container nieuw is, ga dan verder met voorrang en padresolutie.
Pas de voorrang van Compose-omgevingsvariabelen in de juiste volgorde toe
Noteer elke bron voor één onschadelijke variabele: CLI-opties, shellwaarden, environment:, env_file:, standaard of expliciet .env en ENV uit de image.
Docker definieert een formele voorrangsvolgorde voor omgevingsvariabelen, waardoor een correct env-bestand alsnog kan verliezen van een waarde met hogere prioriteit die door de opstartservice of stackbeheerder wordt ingevoegd.
Zoek niet alleen naar dubbele bestandsnamen. Zoek de variabelenaam in het gegenereerde Compose-model, het unitbestand, de instellingen van de beheerder, de shellomgeving en de standaardwaarden van de image.
Controleer de projectmap en relatieve env-paden
Vergelijk de werkmap van de handmatige opdracht met de werkmap van de launcher tijdens het opstarten, de argumenten voor Compose-bestanden, de projectmap en relatieve verwijzingen naar env_file.
De Compose-specificatie definieert het toepassingsmodel waarmee services en configuratie worden opgelost. De geselecteerde projectdefinitie en bijbehorende paden zijn dus invoer voor de implementatie en geen eigenschappen die opnieuw uit de actieve container worden afgeleid.
Gebruik absolute paden voor env-bestanden die essentieel zijn tijdens het opstarten wanneer de implementatietool dit ondersteunt, of stel een expliciete projectmap en werkmap in zodat handmatige en geautomatiseerde starts dezelfde bestanden gebruiken.
Inspecteer de werkmap en omgevingsbestanden van systemd
Lees de effectieve unit, alle drop-ins, WorkingDirectory=, Environment=, EnvironmentFile= en ExecStart=. Vergelijk de unit die tijdens het opstarten wordt geladen met de opdracht die handmatig wordt gebruikt.
De uitvoeringsinstellingen van systemd definiëren de werkmap en omgevingsbestanden van de service. Deze nemen niet automatisch de huidige map of geëxporteerde variabelen van een interactieve aanmeldshell over.
Laad na het wijzigen van een unit of drop-in de systemd-manager opnieuw en inspecteer de effectieve unit nogmaals. Het bewerken van een sjabloon of ongebruikt bestand wijzigt de service die daadwerkelijk start niet.
Controleer variabelen van de stackbeheerder en opgeslagen implementatiestatus
Als Portainer of een NAS-interface de stack beheert, vergelijk dan de opgeslagen variabelen, het geüploade env-bestand, het Git-implementatiepad, het gedrag van webhookupdates en het weergegeven Compose-model.
Portainer maakt onderscheid tussen het gedrag van .env en stack.env, waardoor waarden die in de beheerder zijn ingevoerd kunnen verschillen van een bestand dat rechtstreeks op de host is bewerkt.
Kies één bron van waarheid. Een stack die vanuit Git of een webeditor wordt beheerd, moet na elke herstart niet ook handmatig vanuit een andere lokale kopie worden gestart.
Maak de container opnieuw aan in plaats van deze alleen te herstarten
Vergelijk de aanmaaktijd van de container met de bewerkingstijd van het env-bestand. Genereer de bedoelde Compose-configuratie en voer daarna gecontroleerd een nieuwe aanmaak uit van alleen de betreffende service.
De systemd-richtlijnen van Red Hat adviseren om de bestanden en overschrijvingen te controleren die daadwerkelijk door een service worden gebruikt voordat je deze herstart. Zo voorkom je dat een verouderde unit of wrapper de container opnieuw aanmaakt met oude waarden.
Een containerherstart reconstrueert de omgeving niet vanuit Compose. Maak de container alleen opnieuw aan nadat je persistente gegevens hebt beschermd en hebt bevestigd dat het gegenereerde model naar de bedoelde volumes en geheimen verwijst.
Zorg dat handmatig starten, opnieuw opstarten en opnieuw implementeren hetzelfde model opleveren
Leg de Compose-bestanden, projectnaam, projectmap, het pad naar het env-bestand, de eigenaar van de stack en de opstartafhankelijkheid vast. Bewaar een geredigeerde gegenereerde configuratie en een onschadelijke omgevingsvingerafdruk.
Het ZimaSpace-artikel over de reikwijdte van Docker-back-ups geeft de bijbehorende regel: omgevingsbestanden en implementatiedefinities moeten samen met persistente status worden bewaard.
Het probleem is opgelost wanneer een handmatige nieuwe aanmaak, een herstart van de host, een geplande update en een nieuwe implementatie via de stackbeheerder de service allemaal aanmaken met dezelfde geredigeerde omgevingsvingerafdruk.
Veelgestelde vragen
Wat is het verschil tussen .env en env_file?
Een .env-bestand van een project levert doorgaans interpolatiewaarden aan Compose, terwijl een env_file van een service variabelen aan de container levert. De interactie en voorrang ervan hangen af van het volledige Compose-model.
Laadt het herstarten van een container een gewijzigd env-bestand opnieuw?
Nein. Omgevingswaarden worden ingesteld wanneer de container wordt aangemaakt. De service moet doorgaans opnieuw worden aangemaakt vanuit de gecorrigeerde Compose-configuratie.
Waarom treedt het probleem alleen na een herstart op?
Het herstartpad kan een systemd-unit, planner, door de beheerder opgeslagen variabelen, een andere werkmap of een oudere Compose-kopie gebruiken die verschilt van de handmatige start.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Waarom herstelt een Docker-volume de bestandsinhoud, maar gaan uitgebreide bestandskenmerken verloren?
Een diagnose van volumeterugzetting met een inventaris van xattrs, tar- en Rsync-opties, naamruimten, ondersteuning voor bestemmingen, machtigingen, labels, app-metagegevens en tests.
Waarom behoudt een actieve container zijn oude geheugenlimiet nadat het Compose-bestand is gewijzigd?
Een diagnose van geheugenlimieten met aandacht voor actieve cgroups, herstarten versus opnieuw aanmaken, Compose-velden, harde en zachte limieten, bovenliggende scopes, swap en runtime-heaps.
Waarom maakt het herstarten van een reverse proxy elke sessie voor één zelfgehoste app ongeldig?
Een diagnose van sessieverlies met aandacht voor de reikwijdte van herstarts, cookie-eigenaarschap, geheimenrotatie, cachegestuurde sessies, sticky routing, authenticatiegateways en herstel.
