So ermitteln Sie, welche Container-Abhängigkeit eine Neustartschleife verursacht

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How to Identify Which Container Dependency Is Causing a Restart Loop

Identifizieren Sie die erste Abhängigkeit, die nicht mehr verfügbar ist, bevor die App beendet wird, statt jeden Container, der neu startet, als eigentliche Ursache zu betrachten.

In einem Docker-Compose-Stack kann die sichtbare Anwendung in einer Schleife laufen, weil eine Datenbank noch gestartet wird, Redis nicht erreichbar ist, DNS auf den falschen Dienst verweist, ein Bind-Mount fehlt, ein Secret geändert wurde, eine Migration fehlgeschlagen ist oder die App wegen Speicherdrucks beendet wird. Die schnellste Diagnose erfasst den ersten Beendigungs- und Abhängigkeitsfehler, pausiert automatische Neustarts und testet anschließend jeden erforderlichen Dienst über dasselbe Netzwerk und mit denselben Zugangsdaten, die der fehlschlagende Container verwendet.

Den ersten fehlschlagenden Container finden, nicht den lautesten

Listen Sie für jeden Dienst im Stack die Anzahl der Neustarts, den aktuellen Status, den Health-Status, den letzten Exit-Code und die Startzeit auf. Sortieren Sie die Zeitleiste so, dass der früheste Fehler vor dem erneuten Verbinden oder Neustarten sekundärer Container erscheint.

Der Leitfaden von Netdata zu Neustartschleifen zeigt, wie Exit-Codes und Statusangaben OOM-Kills, Segmentierungsfehler, ordnungsgemäße Beendigungen und durch Health-Checks bedingte Stopps unterscheiden. Ein OOMKilled- oder Exit-Code-Signal kann die Untersuchung von Abhängigkeiten überflüssig machen, wenn der App tatsächlich der Speicher ausgeht oder sie intern abstürzt.

Wenn eine Abhängigkeit zuerst ausfällt, untersuchen Sie diese vor der Anwendung. Wenn die App zuerst mit Fehlern wie „Verbindung abgelehnt“, Zeitüberschreitung, Authentifizierungsfehlern oder fehlenden Dateien beendet wird, ordnen Sie diese Meldung genau der Abhängigkeit zu, die sie verwenden wollte.

Die Neusturmwelle pausieren und einen sauberen Fehler erfassen

Deaktivieren oder überschreiben Sie vorübergehend die Neustartrichtlinie für den betroffenen Dienst und führen Sie ihn einmal im Vordergrund aus oder prüfen Sie seine vollständigen Logs aus einem einzigen Startversuch. Bewahren Sie die Zeitstempel des Docker-Daemons und aller Abhängigkeiten auf.

Wiederholte automatische Neustarts können den ersten aussagekräftigen Fehler mit späteren Verbindungsfehlern überschreiben. Ein Container, der alle paar Sekunden neu startet, kann außerdem seine Datenbank, den DNS-Resolver oder das Log-Volume überlasten und dadurch sekundäre Symptome erzeugen.

Löschen Sie während dieser Erfassung keine Container, Volumes oder Datenbanken. Stoppen Sie nur die Neusturmwelle, reproduzieren Sie den Fehler einmal und speichern Sie Umgebung, Mounts, Netzwerkanbindungen, Befehl und Beendigungsstatus, bevor Sie die Konfiguration ändern.

Alle Abhängigkeiten erfassen, die der Container für die Bereitschaft benötigt

Notieren Sie die erforderliche Datenbank, den Cache, die Nachrichtenwarteschlange, den Objektspeicher, den DNS-Resolver, den Identitätsanbieter, eingebundene Dateien, Secrets und externen APIs der App. Geben Sie auch den erwarteten Dienstnamen, Port, das Protokoll, den Benutzernamen, die Datenbank und den Pfad an.

Dash0 erklärt, dass die Startreihenfolge von Compose nicht automatisch bedeutet, dass der Prozess innerhalb einer Abhängigkeit bereit ist; eine App kann starten, während Postgres noch initialisiert wird. Die Lösung besteht darin, auf den gesunden Status einer Abhängigkeit zu warten, statt lediglich auf ihren laufenden Status.

Kennzeichnen Sie Abhängigkeiten als zwingend erforderlich oder optional. Ein fehlender optionaler Metrikdienst sollte die Hauptanwendung nicht neu starten, während eine nicht verfügbare Datenbank ein kontrolliertes Warten, erneute Versuche oder einen Stopp erfordern kann.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Jede Abhängigkeit aus dem Netzwerk des fehlschlagenden Containers testen

Verwenden Sie einen temporären Diagnose-Container, der mit demselben Netzwerk verbunden ist, oder starten Sie eine unterstützte Shell, bevor die App beendet wird. Testen Sie in dieser Reihenfolge: DNS über den Dienstnamen, TCP-Port, TLS, Authentifizierung, Datenbankabfrage und erforderlicher Pfad.

Der Health-Check-Leitfaden von Last9 zu Compose weist darauf hin, dass Bereitschaftsprüfungen abhängige Dienste daran hindern, zu starten, bevor kritische Komponenten tatsächlich antworten können. Eine hilfreiche Prüfung validiert die von Clients benötigte Dienstfunktion, statt nur zu bestätigen, dass ein Prozess existiert.

Wenn DNS fehlschlägt, überprüfen Sie die Netzwerkmitgliedschaft und Aliase. Wenn die TCP-Verbindung geöffnet wird, aber die Authentifizierung fehlschlägt, vergleichen Sie Secrets und Benutzer. Wenn die Anmeldung funktioniert, aber das erwartete Schema, der Bucket, die Warteschlange oder das Verzeichnis fehlt, beheben Sie die Initialisierung statt des Netzwerks.

Mounts, Secrets und Migrationen als Abhängigkeiten prüfen

Vergleichen Sie die aktuellen Bind-Mounts, benannten Volumes, Berechtigungen, Eigentümer, Umgebungsdateien, Secret-Dateien und die Anwendungsversion mit der letzten funktionierenden Bereitstellung. Ein Container kann seine Datenbank erreichen und dennoch neu starten, weil eine Konfigurationsdatei schreibgeschützt ist oder eine Migration nicht schreiben kann.

Eine Fallstudie zum Containerstart zeigt, dass eine auf Health-Checks basierende Abhängigkeitsreihenfolge verhindern kann, dass eine Anwendung abstürzt, bevor ihre Datenbank bereit ist. Die bedingte Startsequenz ist insbesondere beim ersten Start und während Migrationen wichtig.

Führen Sie Migrationen einmal mit sichtbaren Logs aus und sichern Sie die Datenbank, bevor Sie destruktive Schritte erneut versuchen. Wenn sich die App-Version geändert hat, prüfen Sie, ob die Abhängigkeitsversion und der Pfad für das Schema-Upgrade unterstützt werden.

Dienste in Abhängigkeitsreihenfolge wieder aktivieren und Stabilität prüfen

Starten Sie zuerst die Abhängigkeit auf der untersten Ebene, warten Sie auf ihren tatsächlichen Health-Check, starten Sie anschließend die nächste Ebene und zuletzt die Anwendung. Protokollieren Sie Neustartzähler und Health-Status-Übergänge über mehrere Prüfintervalle hinweg.

Der ZimaSpace-Leitfaden zu DNS-Fehlern innerhalb von Containern behandelt einen Abhängigkeitspfad, der möglicherweise nur innerhalb der App-Umgebung auftritt.

Das Problem ist erst behoben, wenn die Anwendung einmal startet, alle zwingend erforderlichen Abhängigkeiten dauerhaft gesund bleiben, Migrationen abgeschlossen werden und ein absichtlicher Neustart einer Abhängigkeit eine kontrollierte Wiederholung oder Wiederherstellung statt einer weiteren Schleife auslöst. Aktivieren Sie eine Neustartrichtlinie erst wieder, wenn der Grundfehler beobachtbar und eingegrenzt ist.