Hoe identificeer je welke containerafhankelijkheid een herstartlus veroorzaakt

Identificeer de eerste afhankelijkheid die niet meer beschikbaar is voordat de app wordt afgesloten, in plaats van elke container die opnieuw wordt gestart als hoofdoorzaak te beschouwen.

In een Docker Compose-stack kan de zichtbare applicatie blijven herstarten omdat een database nog wordt gestart, Redis onbereikbaar is, DNS naar de verkeerde service verwijst, een bind-mount ontbreekt, een secret is gewijzigd, een migratie is mislukt of de app door geheugendruk wordt beëindigd. De snelste diagnose legt de eerste afsluiting en afhankelijkheidsfout vast, pauzeert automatische herstarts en test vervolgens elke vereiste service vanaf hetzelfde netwerk en met dezelfde inloggegevens als de container die faalt.

Vind de eerste container die faalt, niet de luidruchtigste

Bekijk voor elke service in de stack het aantal herstarts, de huidige status, de gezondheidsstatus, de laatste exitcode en de starttijd. Sorteer de tijdlijn zodat de vroegste fout zichtbaar is voordat secundaire containers opnieuw verbinding proberen te maken of worden herstart.

De handleiding van Netdata over herstartlussen laat zien hoe exitcodes en statussen OOM-kills, segmentation faults, normale beëindiging en stops vanwege de gezondheidsstatus van elkaar onderscheiden. Een OOMKilled- of exitcodesignaal kan onderzoek naar afhankelijkheden overbodig maken wanneer de app in werkelijkheid onvoldoende geheugen heeft of intern crasht.

Als één afhankelijkheid als eerste faalt, onderzoek die dan vóór de applicatie. Als de app als eerste afsluit met fouten zoals connection refused, time-outs, authenticatieproblemen of ontbrekende bestanden, koppel die melding dan aan de exacte afhankelijkheid die de app probeerde te gebruiken.

Pauzeer de herstartstorm en leg één schone fout vast

Schakel het herstartbeleid voor de getroffen service tijdelijk uit of overschrijf het, en voer de service één keer op de voorgrond uit of bekijk de volledige logs van één startpoging. Bewaar de tijdstempels van de Docker-daemon en van elke afhankelijkheid.

Herhaalde automatische herstarts kunnen de eerste betekenisvolle fout overschrijven met latere verbindingsfouten. Een container die elke paar seconden opnieuw wordt gestart, kan bovendien de database, DNS-resolver of logopslag overbelasten en secundaire symptomen veroorzaken.

Verwijder tijdens deze vastlegging geen containers, volumes of databases. Stop alleen de herstartstorm, reproduceer het probleem één keer en sla de omgeving, mounts, netwerkverbindingen, opdracht en exitstatus op voordat je de configuratie wijzigt.

Breng elke afhankelijkheid in kaart die de container nodig heeft om gereed te zijn

Noteer de vereiste database, cache, berichtenwachtrij, objectopslag, DNS-resolver, identiteitsprovider, gemounte bestanden, secrets en externe API's van de app. Vermeld ook de verwachte servicenaam, poort, protocol, gebruikersnaam, database en het pad.

Dash0 legt uit dat de opstartvolgorde van Compose niet automatisch betekent dat het proces binnen een afhankelijkheid gereed is; een app kan starten terwijl Postgres nog wordt geïnitialiseerd. De oplossing is wachten op de gezonde status van een afhankelijkheid in plaats van alleen op de status dat deze draait.

Markeer afhankelijkheden als vereist of optioneel. Een ontbrekende optionele metricsservice mag de hoofdapp niet herstarten, terwijl een niet-beschikbare database een gecontroleerde wachttijd, nieuwe poging of stopzetting kan vereisen.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Test elke afhankelijkheid vanaf het netwerk van de falende container

Gebruik een tijdelijke diagnostische container die met hetzelfde netwerk is verbonden, of start een ondersteunde shell voordat de app wordt afgesloten. Test achtereenvolgens DNS voor de servicenaam, de TCP-poort, TLS, authenticatie, een databasequery en het vereiste pad.

De healthcheck-handleiding van Last9 voor Compose merkt op dat gereedheidscontroles voorkomen dat afhankelijke services starten voordat kritieke componenten daadwerkelijk kunnen reageren. Een nuttige controle valideert de servicebewerking die clients nodig hebben in plaats van alleen te bevestigen dat er een proces bestaat.

Als DNS faalt, controleer dan het netwerklidmaatschap en de aliassen. Als de TCP-verbinding tot stand komt maar authenticatie faalt, vergelijk dan de secrets en gebruikers. Als inloggen lukt maar het verwachte schema, de bucket, wachtrij of map ontbreekt, herstel dan de initialisatie in plaats van het netwerk.

Controleer mounts, secrets en migraties als afhankelijkheden

Vergelijk de huidige bind-mounts, benoemde volumes, machtigingen, eigenaars, omgevingsbestanden, secretbestanden en applicatieversie met de laatst werkende implementatie. Een container kan zijn database bereiken en toch opnieuw starten omdat een configuratiebestand alleen-lezen is of een migratie niet kan schrijven.

Een casestudy over het starten van containers laat zien dat een afhankelijkheidsvolgorde op basis van de gezondheidsstatus kan voorkomen dat een applicatie crasht voordat de database gereed is. De voorwaardelijke opstartvolgorde is vooral belangrijk tijdens de eerste start en bij migraties.

Voer migraties één keer uit terwijl de logs zichtbaar zijn en maak een back-up van de database voordat je destructieve stappen opnieuw probeert. Als de appversie is gewijzigd, controleer dan of de versie van de afhankelijkheid en het pad voor de schem upgrade worden ondersteund.

Schakel services opnieuw in volgens de afhankelijkheidsvolgorde en controleer de stabiliteit

Start eerst de afhankelijkheid op het laagste niveau, wacht op de daadwerkelijke healthcheck en start vervolgens de volgende laag en ten slotte de applicatie. Noteer het aantal herstarts en de overgangen in de gezondheidsstatus gedurende meerdere controle-intervallen.

De ZimaSpace-handleiding over DNS-fouten aan de containerzijde behandelt een afhankelijkheidspad dat alleen binnen de appomgeving zichtbaar kan worden.

Het probleem is pas opgelost wanneer de applicatie één keer start, alle vereiste afhankelijkheden gezond blijven, migraties zijn voltooid en een bewuste herstart van een afhankelijkheid leidt tot gecontroleerd opnieuw proberen of herstel in plaats van opnieuw een lus. Schakel het herstartbeleid pas weer in nadat de hoofdfout zichtbaar en begrensd is.