Warum verwendet ein Compose-Dienst erst nach einem Neustart des Hosts die falsche Env-Datei?
Ein Compose-Dienst kann nach einem Neustart andere Umgebungswerte verwenden, wenn der Launcher beim Booten ein anderes Projektverzeichnis, eine andere Env-Datei oder eine andere Quelle mit höherer Priorität auflöst.
Ein manueller Befehl kann im vorgesehenen Ordner mit einer bestimmten Shell-Umgebung ausgeführt werden, während systemd, ein NAS-Scheduler oder Portainer dieselbe Compose-Datei nach dem Booten aus einem anderen Kontext startet. Der Dienst kann außerdem einen vorhandenen Container neu starten, dessen Umgebung zum Erstellungszeitpunkt festgelegt wurde, anstatt die bearbeitete Datei erneut einzulesen. Vergleichen Sie das gerenderte Compose-Modell und die Umgebung des laufenden Prozesses aus dem manuellen und dem Boot-Pfad, bevor Sie mehrere Dateien gleichzeitig bearbeiten.
Laufende Umgebung mit der vorgesehenen Datei vergleichen
Notieren Sie die Container-ID, die Erstellungszeit, das Image, die Compose-Labels, den Projektnamen und die tatsächlich im Hauptprozess sichtbaren Werte. Vergleichen Sie diese mit der vorgesehenen Env-Datei, ohne Geheimnisse in gemeinsam genutzte Protokolle zu schreiben.
Die Linux-Prozessumgebung stellt die bei der Ausführung übergebenen Werte bereit. Das ist ein stärkerer Beleg als das Lesen einer Env-Datei, die der aktuelle Container möglicherweise nie verwendet hat.
Wenn der Container die alten Werte enthält und vor der Bereitstellung beim Neustart erstellt wurde, wurde er möglicherweise lediglich neu gestartet. Wenn der Container neu ist, fahren Sie mit der Prüfung der Prioritäten und der Pfadauflösung fort.
Compose-Umgebungsprioritäten in der richtigen Reihenfolge anwenden
Listen Sie für eine unkritische Variable jede Quelle auf: CLI-Flags, Shell-Werte, environment:, env_file:, die standardmäßige oder explizite .env-Datei und ENV des Images.
Docker definiert eine formale Prioritätsreihenfolge für Umgebungsvariablen. Daher kann eine korrekte Env-Datei trotzdem durch einen Wert mit höherer Priorität überschrieben werden, den der Boot-Dienst oder Stack-Manager einschleust.
Suchen Sie nicht nur nach doppelten Dateinamen. Suchen Sie den Variablennamen im gerenderten Compose-Modell, in der Unit-Datei, den Manager-Einstellungen, der Shell-Umgebung und den Image-Standardeinstellungen.
Projektverzeichnis und relative Env-Pfade prüfen
Vergleichen Sie das Arbeitsverzeichnis des manuellen Befehls mit dem Arbeitsverzeichnis des Boot-Launchers, den Argumenten für die Compose-Datei, dem Projektverzeichnis und den relativen env_file-Verweisen.
Die Compose-Spezifikation definiert das Anwendungsmodell zur Auflösung von Diensten und Konfiguration. Daher sind die ausgewählte Projektdefinition und ihre Pfade Eingaben für die Bereitstellung und keine Eigenschaften, die aus dem laufenden Container erneut ermittelt werden.
Verwenden Sie für beim Booten kritische Env-Dateien absolute Pfade, sofern das Bereitstellungstool dies unterstützt, oder legen Sie ein explizites Projekt- und Arbeitsverzeichnis fest, damit manuelle und automatisierte Starts dieselben Dateien auflösen.
Arbeitsverzeichnis und Umgebungsdateien von systemd prüfen
Lesen Sie die effektive Unit, alle Drop-ins, WorkingDirectory=, Environment=, EnvironmentFile= und ExecStart=. Vergleichen Sie die beim Booten geladene Unit mit dem manuell verwendeten Befehl.
Die Ausführungseinstellungen von systemd definieren das Arbeitsverzeichnis und die Umgebungsdateien des Dienstes. Sie übernehmen nicht automatisch das aktuelle Verzeichnis oder exportierte Variablen einer interaktiven Login-Shell.
Nach der Änderung einer Unit oder eines Drop-ins laden Sie den systemd-Manager neu und prüfen Sie die effektive Unit erneut. Das Bearbeiten einer Vorlage oder einer nicht verwendeten Datei ändert nicht den Dienst, der tatsächlich gestartet wird.
Variablen des Stack-Managers und gespeicherten Bereitstellungsstatus prüfen
Wenn Portainer oder eine NAS-Benutzeroberfläche den Stack verwaltet, vergleichen Sie die gespeicherten Variablen, die hochgeladene Env-Datei, den Git-Bereitstellungspfad, das Verhalten bei Webhook-Aktualisierungen und das angezeigte Compose-Modell.
Portainer unterscheidet zwischen dem Verhalten von .env und stack.env. Daher können sich im Manager eingegebene Werte von einer direkt auf dem Host bearbeiteten Datei unterscheiden.
Bestimmen Sie eine einzige Quelle der Wahrheit. Ein aus Git oder einem Webeditor verwalteter Stack sollte nach jedem Neustart nicht zusätzlich manuell aus einer anderen lokalen Kopie gestartet werden.
Container neu erstellen, statt ihn nur neu zu starten
Vergleichen Sie die Erstellungszeit des Containers mit dem Änderungszeitpunkt der Env-Datei. Rendern Sie die vorgesehene Compose-Konfiguration und erstellen Sie anschließend kontrolliert nur den betroffenen Dienst neu.
Die systemd-Anleitung von Red Hat empfiehlt, die tatsächlich von einem Dienst verwendeten Dateien und Überschreibungen zu prüfen, bevor er neu gestartet wird. So verhindern Sie, dass eine veraltete Unit oder ein Wrapper den Container mit alten Werten neu erstellt.
Ein Neustart des Containers rekonstruiert seine Umgebung nicht aus Compose. Erstellen Sie ihn erst neu, nachdem Sie persistente Daten geschützt und bestätigt haben, dass das gerenderte Modell auf die vorgesehenen Volumes und Secrets verweist.
Manueller Start, Neustart und erneute Bereitstellung auf dasselbe Modell ausrichten
Fixieren Sie die Compose-Dateien, den Projektnamen, das Projektverzeichnis, den Pfad zur Env-Datei, den Besitzer des Stacks und die Boot-Abhängigkeit. Speichern Sie eine bereinigte Konfiguration und einen unkritischen Umgebungs-Fingerabdruck.
Der ZimaSpace-Artikel zum Umfang von Docker-Backups liefert die ergänzende Regel: Env-Dateien und Bereitstellungsdefinitionen müssen zusammen mit dem persistenten Zustand aufbewahrt werden.
Das Problem ist gelöst, wenn eine manuelle Neuerstellung, ein Host-Neustart, eine geplante Aktualisierung und eine erneute Bereitstellung über den Stack-Manager den Dienst jeweils mit demselben bereinigten Umgebungs-Fingerabdruck erstellen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen .env und env_file?
Eine projektbezogene .env-Datei liefert Compose üblicherweise Interpolationswerte, während eine servicebezogene env_file Variablen für den Container bereitstellt. Ihre Wechselwirkung und Priorität hängen vom vollständigen Compose-Modell ab.
Lädt ein Neustart des Containers eine geänderte Env-Datei neu?
Nein. Umgebungswerte werden bei der Erstellung des Containers festgelegt. Der Dienst muss normalerweise anhand der korrigierten Compose-Konfiguration neu erstellt werden.
Warum tritt das Problem nur nach einem Neustart auf?
Der Neustartpfad verwendet möglicherweise eine systemd-Unit, einen Scheduler, im Manager gespeicherte Variablen, ein anderes Arbeitsverzeichnis oder eine ältere Compose-Kopie, die sich vom manuellen Start unterscheidet.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
Warum stellt eine Docker-Volume-Wiederherstellung zwar die Dateiinhalte wieder her, lässt aber erweiterte Attribute weg?
Eine Diagnose zur Wiederherstellung von Volumes mit einer Bestandsaufnahme der erweiterten Attribute, Tar- und Rsync-Optionen, Namespaces, Zielunterstützung, Berechtigungen, Labels, App-Metadaten und Tests.
Warum behält ein laufender Container sein altes Speicherlimit bei, nachdem die Compose-Datei geändert wurde?
Eine Diagnose der Speicherbegrenzung mit Erläuterungen zu aktiven cgroups, Neustart gegenüber Neuerstellung, Compose-Feldern, harten und weichen Limits, übergeordneten Bereichen, Swap sowie Laufzeit-Heaps.
Warum macht ein Neustart des Reverse-Proxys jede Sitzung für eine selbst gehostete App ungültig?
Eine Diagnose von Sitzungsverlusten mit Abdeckung des Neustartumfangs, der Cookie-Zuständigkeit, der Geheimnisrotation, cachebasierten Sitzungen, Sticky-Routing, Authentifizierungs-Gateways und der Wiederherstellung.
