Waarom mislukt een gezondheidscontrole van een container terwijl de app nog steeds opent?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Een container kan bruikbaar blijven terwijl de gezondheidscontrole mislukt, omdat de controle een ander commando, adres, andere gebruiker of gereedheidsvoorwaarde test dan het pad dat je browser gebruikt.

Op een thuisserver kan de app via een reverse proxy worden geopend, terwijl Docker het gezondheidscommando in de container uitvoert tegen localhost, een ontbrekend hulpprogramma, de verkeerde poort of een tijdelijk niet-beschikbare afhankelijkheid. Begin met het exact reproduceren van de controle in de container. Vergelijk vervolgens het doel en het verwachte resultaat ervan met het werkelijke pad dat de gebruiker volgt, voordat je het aantal pogingen verhoogt of de gezondheidscontrole uitschakelt.

Vergelijk wat de browser test met wat de gezondheidscontrole test

Noteer de URL en het netwerkpad waarmee de applicatie succesvol wordt geopend. Let erop of de browser een reverse proxy, een gepubliceerde hostpoort, een lokaal IP-adres of de container rechtstreeks bereikt.

Docker voert de geconfigureerde controle uit in de container, waardoor mogelijk een ander eindpunt wordt getest dan door de browser. In een geval uit de Docker-community mislukte een gezondheidscontrole omdat de image niet het curl-commando dat door de controle werd gebruikt bevatte, hoewel het serviceproces zelf nog gewoon kon werken.

Als het succesvolle browserpad via een andere proxy of poort loopt, beschouw dat dan niet als bewijs dat het interne doel van de controle juist is. Schrijf beide paden op en bepaal welk eerste onderdeel verschilt.

Voer het exacte gezondheidscommando uit in de container

Kopieer het gezondheidscommando exact, inclusief de shellvorm, URL, opties, inloggegevens en omgevingsvariabelen. Voer het uit in de actieve container als dezelfde gebruiker en leg de afsluitcode en uitvoer vast.

Een container die als ongezond is gemarkeerd, kan nog steeds een actief proces hebben, omdat de gezondheidsstatus het resultaat van de controle weergeeft en niet bepaalt of gebruikers één pagina kunnen laden. De diagnostische werkwijze van Netdata maakt onderscheid tussen een mislukte controle en een mislukt proces voordat het herstartgedrag wordt aangepast.

Als het commando handmatig slaagt, vergelijk dan de uitvoerende gebruiker, shell, werkdirectory, omgeving en timing met die van de automatische controle. Als het handmatig mislukt, geeft de fout nu aan welke laag je moet onderzoeken, zonder op een volgende controle-interval te hoeven wachten.

Controleer het hulpprogramma, de shell, PATH en gebruiker van de controle

Bevestig dat elk uitvoerbaar bestand in het gezondheidscommando in de huidige image aanwezig is en door de containergebruiker kan worden uitgevoerd. Minimale images bevatten mogelijk geen curl, wget, bash, DNS-hulpprogramma’s of certificaatopslag.

Controles in shellvorm en exec-vorm gedragen zich verschillend. Aanhalingstekens, pipes, variabele-expansie en samengestelde commando’s vereisen een beschikbare shell, terwijl een rechtstreeks commando het volledige pad naar het uitvoerbare bestand nodig heeft wanneer de omgeving van de gezondheidscontrole een beperkte PATH heeft.

Voer het commando uit met een absoluut pad en de beoogde servicegebruiker. Pas de image of de controle aan in plaats van hulpprogramma’s interactief te installeren, want een handmatige wijziging in de container verdwijnt bij de volgende build.

Controleer het interne adres, de poort en het protocol

Bekijk op welk adres en welke poort de applicatie in de container luistert en vergelijk dit met de URL van de controle. Een gepubliceerde hostpoort zoals 8080:80 betekent niet dat de service in de container op poort 8080 luistert.

Gezondheidscontroles moeten de applicatiestatus testen waar de container controle over heeft. In de praktische handleiding van Dash0 staat dat een controle een HTTP-eindpunt kan aanroepen of een proces kan inspecteren, maar dat het eindpunt de werkelijke gereedheidsstatus van de container moet weerspiegelen, in plaats van een route die alleen via een externe proxy beschikbaar is.

Test 127.0.0.1, het adres waarop de container luistert en de servicenaam alleen waar dat passend is. Als de app uitsluitend aan een Unix-socket of een andere interface is gebonden, pas de controle dan aan naar het werkelijke interne toegangspunt.

Maak onderscheid tussen langzaam opstarten en een permanente fout

Meet hoe lang het duurt voordat de applicatie, databasemigratie, cache-opwarming of modellading gereed is en het juiste eindpunt antwoordt. Vergelijk die tijd met start_period, interval, timeout en retries.

Compose kan afhankelijke services blokkeren wanneer een afhankelijkheid nog steeds als ongezond is gemarkeerd, ook al wordt deze later gereed. In een gemelde Compose-regressie werd een service pas gezond nadat het mislukken van de afhankelijkheid de stack al had gestopt. Daarmee werd een te kort opstartvenster voor de gezondheidscontrole zichtbaar.

Verhoog de timing alleen wanneer logs aantonen dat de app normaal voortgang boekt. Langere wachttijden mogen geen verkeerde poort, mislukte migratie, ontbrekend certificaat of onbereikbare database verbergen.

Houd de controle beperkt en verifieer herstel

Bepaal of de gezondheidscontrole procesbeschikbaarheid, lokale applicatiegereedheid of een diepere keten van afhankelijkheden moet weergeven. Markeer een lokale container niet als ongezond alleen omdat een optionele externe API niet beschikbaar is.

De ZimaSpace-handleiding over het vinden van de eerste mislukte afhankelijkheid is de volgende stap wanneer de applicatie zelf niet gereed kan worden zonder een database, cache of netwerkservice.

Het probleem is opgelost wanneer de exacte automatische controle na normaal opstarten slaagt, de container gezond blijft tijdens herstarts van afhankelijkheden en de werkelijke app-workflow beschikbaar blijft. Houd de controle streng genoeg om een defecte service te detecteren, maar beperkt genoeg om onterechte fouten door niet-gerelateerde systemen te voorkomen.

Ondersteuning & Tips

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.