Warum schlägt die Gesundheitsprüfung eines Containers fehl, während die App weiterhin geöffnet werden kann?

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.

Why Does a Container Health Check Fail While the App Still Opens? - Zima Store Online

Ein Container kann weiterhin nutzbar sein, obwohl sein Healthcheck fehlschlägt, weil die Prüfung einen anderen Befehl, eine andere Adresse, einen anderen Benutzer oder eine andere Bereitschaftsbedingung testet als der von Ihrem Browser verwendete Pfad.

Auf einem Heimserver lässt sich die App möglicherweise über einen Reverse-Proxy öffnen, obwohl Docker den Healthcheck-Befehl innerhalb des Containers gegen localhost, ein fehlendes Dienstprogramm, den falschen Port oder eine vorübergehend nicht verfügbare Abhängigkeit ausführt. Beginnen Sie damit, die exakte Prüfung innerhalb des Containers nachzustellen. Vergleichen Sie anschließend deren Ziel und erwartetes Ergebnis mit dem tatsächlichen Benutzerpfad, bevor Sie die Anzahl der Wiederholungsversuche erhöhen oder den Healthcheck deaktivieren.

Vergleichen Sie, was der Browser und was der Healthcheck testet

Notieren Sie die URL und den Netzwerkpfad, über die sich die Anwendung erfolgreich öffnen lässt. Halten Sie fest, ob der Browser einen Reverse-Proxy, einen veröffentlichten Host-Port, eine lokale IP-Adresse oder den Container direkt erreicht.

Docker führt die konfigurierte Prüfung innerhalb des Containers aus. Daher kann sie einen anderen Endpunkt testen als der Browser. Ein Fall aus der Docker-Community zeigte, dass ein Healthcheck fehlschlug, weil das Image den vom Prüfskript verwendeten curl-Befehl nicht enthielt, obwohl der Dienstprozess selbst weiterhin ausgeführt werden konnte.

Wenn der erfolgreiche Browserpfad über einen anderen Proxy oder Port führt, betrachten Sie dieses Ergebnis nicht als Beweis dafür, dass das interne Prüfziel korrekt ist. Schreiben Sie beide Pfade auf und ermitteln Sie die erste Komponente, in der sie sich unterscheiden.

Führen Sie den exakten Healthcheck-Befehl im Container aus

Kopieren Sie den Healthcheck-Befehl exakt, einschließlich Shell-Form, URL, Optionen, Zugangsdaten und Umgebungsvariablen. Führen Sie ihn im laufenden Container als derselbe Benutzer aus und erfassen Sie Exit-Code und Ausgabe.

Ein als „unhealthy“ markierter Container kann weiterhin einen laufenden Prozess haben, da der Gesundheitsstatus das Ergebnis der Prüfung widerspiegelt und nicht, ob Benutzer eine Seite laden können. Der Diagnoseablauf von Netdata unterscheidet zunächst Prüfungsfehler und Prozessfehler, bevor das Neustartverhalten geändert wird.

Wenn der Befehl manuell erfolgreich ist, vergleichen Sie den für die automatische Prüfung verwendeten Benutzer, die Shell, das Arbeitsverzeichnis, die Umgebung und den zeitlichen Ablauf. Wenn er manuell fehlschlägt, zeigt der Fehler nun die nächste Ebene an, ohne dass Sie auf das nächste Prüfintervall warten müssen.

Prüfen Sie Prüfprogramm, Shell, PATH und Benutzer

Stellen Sie sicher, dass jedes ausführbare Programm im Healthcheck-Befehl im aktuellen Image vorhanden ist und vom Containerbenutzer ausgeführt werden kann. In schlanken Images fehlen möglicherweise curl, wget, bash, DNS-Tools oder Zertifikatsspeicher.

Prüfungen in Shell-Form und Exec-Form verhalten sich unterschiedlich. Anführungszeichen, Pipes, Variablenexpansion und zusammengesetzte Befehle benötigen eine verfügbare Shell, während ein direkter Befehl den vollständigen Pfad zur ausführbaren Datei benötigt, wenn die Healthcheck-Umgebung über einen eingeschränkten PATH verfügt.

Führen Sie den Befehl mit einem absoluten Pfad und dem vorgesehenen Dienstbenutzer aus. Beheben Sie das Image oder die Prüfung, statt Tools interaktiv zu installieren, da eine manuelle Änderung am Container beim nächsten Neubau verloren geht.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Überprüfen Sie interne Adresse, Port und Protokoll

Prüfen Sie, an welcher Adresse und an welchem Port die Anwendung im Container lauscht, und vergleichen Sie dies mit der Prüf-URL. Ein veröffentlichter Host-Port wie 8080:80 bedeutet nicht, dass der Dienst innerhalb des Containers auf Port 8080 lauscht.

Healthchecks sollten den von diesem Container kontrollierten Anwendungsstatus testen. Der praxisnahe Leitfaden von Dash0 weist darauf hin, dass eine Prüfung einen HTTP-Endpunkt aufrufen oder einen Prozess untersuchen kann. Der Endpunkt muss jedoch den tatsächlichen Bereitschaftsstatus des Containers widerspiegeln und darf nicht nur eine über einen externen Proxy verfügbare Route prüfen.

Testen Sie 127.0.0.1, die Listener-Adresse des Containers und den Dienstnamen nur dort, wo sie jeweils geeignet sind. Wenn die App ausschließlich an einen Unix-Socket oder eine andere Schnittstelle gebunden ist, ändern Sie die Prüfung auf den tatsächlichen internen Einstiegspunkt.

Unterscheiden Sie zwischen langsamem Start und dauerhaftem Fehler

Messen Sie, wie lange die Anwendung, die Datenbankmigration, das Aufwärmen des Caches oder das Laden des Modells benötigt, bevor der korrekte Endpunkt antwortet. Vergleichen Sie diese Zeit mit start_period, interval, timeout und retries.

Compose kann abhängige Dienste blockieren, wenn eine Abhängigkeit weiterhin als nicht gesund markiert ist, obwohl sie später bereit wird. Eine gemeldete Compose-Regression zeigte, dass ein Dienst erst gesund wurde, nachdem der Fehler der Abhängigkeit den Stack bereits beendet hatte. Dadurch wurde ein zu knapp bemessenes Zeitfenster für den Start des Healthchecks sichtbar.

Verlängern Sie die Zeitvorgaben nur, wenn die Logs zeigen, dass die App normal fortschreitet. Mehr Wiederholungsversuche sollten keinen falschen Port, eine fehlgeschlagene Migration, ein fehlendes Zertifikat oder eine nicht erreichbare Datenbank verschleiern.

Halten Sie die Prüfung eng gefasst und überprüfen Sie die Wiederherstellung

Entscheiden Sie, ob der Healthcheck die Prozess-Liveness, die lokale Anwendungsbereitschaft oder eine tiefergehende Kette von Abhängigkeiten abbilden soll. Markieren Sie einen lokalen Container nicht allein deshalb als nicht gesund, weil eine optionale externe API nicht verfügbar ist.

Der ZimaSpace-Leitfaden zum Auffinden der zuerst fehlgeschlagenen Abhängigkeit ist der nächste Schritt, wenn die Anwendung ohne eine Datenbank, einen Cache oder einen Netzwerkdienst nicht bereit werden kann.

Das Problem ist behoben, wenn die exakte automatische Prüfung nach dem normalen Start erfolgreich ist, der Container Neustarts von Abhängigkeiten übersteht und der tatsächliche App-Workflow verfügbar bleibt. Halten Sie die Prüfung streng genug, um einen defekten Dienst zu erkennen, aber eng genug, um Fehlalarme durch nicht verbundene Systeme zu vermeiden.