Varför misslyckas en containers hälsokontroll när appen fortfarande öppnas?

En container kan fortfarande vara användbar trots att dess hälsokontroll misslyckas, eftersom kontrollen testar ett annat kommando, en annan adress, användare eller beredskapsförutsättning än den väg som din webbläsare använder.

På en hemmaserver kan appen öppnas via en omvänd proxy, även om Docker kör hälsokommandot inuti containern mot localhost, ett verktyg som saknas, fel port eller ett beroende som tillfälligt inte är tillgängligt. Börja med att återskapa den exakta kontrollen inuti containern. Jämför sedan dess mål och förväntade resultat med den verkliga användarvägen innan du ökar antalet försök eller inaktiverar hälsokontrollen.

Jämför vad webbläsaren testar med vad hälsokontrollen testar

Notera URL:en och nätverksvägen som öppnar appen. Kontrollera om webbläsaren når en omvänd proxy, en publicerad värdport, en lokal IP-adress eller containern direkt.

Docker kör den konfigurerade kontrollen inuti containern, så den kan testa en annan slutpunkt än webbläsaren. I ett fall i Docker Community misslyckades en hälsokontroll eftersom avbildningen inte innehöll curl-kommandot som kontrollen använde, trots att själva tjänsteprocessen fortfarande kunde köras.

Om den fungerande webbläsarvägen går via en annan proxy eller port ska du inte se det som ett bevis på att den interna kontrollens mål är korrekt. Skriv ned båda vägarna och identifiera den första komponent som skiljer sig.

Kör det exakta hälsokommandot inuti containern

Kopiera hälsokontrollens kommando exakt, inklusive dess skalform, URL, flaggor, inloggningsuppgifter och miljövariabler. Kör det inuti den körande containern som samma användare och spara avslutningskoden och resultatet.

En container som markerats som ohälsosam kan fortfarande ha en körande process, eftersom hälsostatusen återspeglar kontrollens resultat och inte huruvida användare kan läsa in en sida. Netdatas diagnostikarbetsflöde skiljer mellan kontrollfel och processfel innan omstartsverifieringen ändras.

Om kommandot lyckas manuellt ska du jämföra användaren, skalet, arbetskatalogen, miljön och tidsinställningarna som används av den automatiska kontrollen. Om det misslyckas manuellt identifierar felet nu nästa lager utan att du behöver vänta på nästa kontrollintervall.

Kontrollera kontrollverktyget, skalet, PATH och användaren

Bekräfta att varje körbar fil i hälsokommandot finns i den aktuella avbildningen och kan köras av containeranvändaren. Minimala avbildningar kan sakna curl, wget, bash, DNS-verktyg eller certifikatarkiv.

Kontroller i skalform och exec-form fungerar olika. Citering, rör, variabelexpansion och sammansatta kommandon kräver ett tillgängligt skal, medan ett direkt kommando behöver den fullständiga sökvägen till den körbara filen när hälsokontrollens miljö har en begränsad PATH.

Kör kommandot med en absolut sökväg och den avsedda tjänsteanvändaren. Åtgärda avbildningen eller kontrollen i stället för att installera verktyg interaktivt, eftersom en manuell ändring av containern försvinner vid nästa ombyggnad.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifiera intern adress, port och protokoll

Kontrollera vilken lyssnare appen använder inuti containern och jämför den med kontrollens URL. En publicerad värdport som 8080:80 betyder inte att tjänsten lyssnar på port 8080 inuti containern.

Hälsokontroller bör testa det apptillstånd som containern ansvarar för. Dash0:s praktiska guide påpekar att en kontroll kan anropa en HTTP-slutpunkt eller granska en process, men slutpunkten måste återspegla containerns faktiska beredskapstillstånd i stället för en rutt som endast är tillgänglig via en extern proxy.

Testa 127.0.0.1, containerns lyssnaradress och tjänstenamnet endast där respektive alternativ är lämpligt. Om appen endast binder till en Unix-socket eller ett annat gränssnitt ska du ändra kontrollen till den verkliga interna ingångspunkten.

Skilj långsam uppstart från ett permanent fel

Mät hur lång tid det tar innan appen, databasmigreringen, cacheuppvärmningen eller modellinläsningen har slutförts och den korrekta slutpunkten svarar. Jämför tiden med start_period, interval, timeout och retries.

Compose kan blockera beroende tjänster när ett beroende fortfarande är markerat som ohälsosamt, även om det blir klart senare. En rapporterad Compose-regression visade att en tjänst blev frisk först efter att beroendefelet redan hade stoppat stacken, vilket avslöjade ett för snävt tidsfönster för hälsokontrollen vid uppstart.

Öka tidsgränserna endast när loggarna visar att appen gör normala framsteg. Fler och längre försök ska inte dölja en felaktig port, en misslyckad migrering, ett saknat certifikat eller en databas som inte kan nås.

Håll kontrollen avgränsad och verifiera återhämtning

Bestäm om hälsokontrollen ska representera processens livstecken, den lokala appens beredskap eller en djupare kedja av beroenden. Gör inte en lokal container ohälsosam enbart för att ett valfritt externt API är otillgängligt.

ZimaSpaces guide om att hitta det första beroendet som misslyckas är nästa steg när själva appen inte kan bli klar utan en databas, cache eller nätverkstjänst.

Problemet är löst när den exakta automatiska kontrollen lyckas efter normal uppstart, containern förblir frisk genom omstarter av beroenden och det verkliga apparbetsflödet fortfarande är tillgängligt. Håll kontrollen tillräckligt strikt för att upptäcka en trasig tjänst, men tillräckligt avgränsad för att undvika falska fel från orelaterade system.