Hoe je Docker-herstartbeleid afstemt op databases, workers en webapps

Stem Docker-herstartbeleid af op de levenscyclus en afsluitsemantiek van de service, in plaats van aan elke container in een Compose-bestand unless-stopped toe te wijzen.

Herstartbeleid reageert wanneer het hoofdproces van een container wordt afgesloten; een healthcheck kan een nog actief proces als ongezond markeren zonder het automatisch opnieuw te starten. Databases, workers, webapps, migraties en geplande taken hebben daarom verschillende keuzes nodig, afhankelijk van de vraag of ze actief moeten blijven, wat een normale afsluiting betekent en hoe herhaalde fouten zichtbaar moeten worden gemaakt.

Scheid herstartgedrag van gezondheid en gereedheid

Een herstartbeleid bepaalt of Docker een container opnieuw moet starten nadat het proces is gestopt. Een healthcheck bepaalt of de actieve service een bepaalde bewerking kan uitvoeren. Afhankelijkheids-gereedheid bepaalt of een andere service al mag starten. Ze lossen verwante, maar verschillende problemen op.

Een uitleg over gezondheid en herstarten als afzonderlijke zaken uit 2026 verduidelijkt deze scheiding en laat zien hoe gezondheidsvoorwaarden in Compose de start van afhankelijke services kunnen uitstellen totdat een service daadwerkelijk gereed is.

Verwacht niet dat restart: always een ongezond webproces repareert dat nooit wordt afgesloten, en verwacht ook niet dat een healthcheck het proces automatisch herstart. Laat de applicatie afsluiten wanneer doorgaan onveilig is, voeg een extern herstelmechanisme toe of waarschuw bij een ongezonde status, afhankelijk van het serviceontwerp.

Gebruik persistent herstartbeleid voor langlopende databases

Van een database op een thuisserver wordt normaal gesproken verwacht dat deze na het herstarten van de host of Docker-daemon terugkeert. unless-stopped is vaak een praktische standaard wanneer een opzettelijke stop door een beheerder gerespecteerd moet blijven; always is geschikt wanneer een herstart volgens het ontwerp een eerdere handmatige stop moet overrulen.

Een uitleg over herstartbeleid en procesafsluiting uit juli 2026 beschrijft de verschillen tussen no, on-failure, always en unless-stopped, inclusief het feit dat het beleid reageert op het afsluiten van het proces en niet op de gezondheidsstatus.

De database heeft ook een echte healthcheck en duurzame opslag nodig. PostgreSQL herhaaldelijk herstarten kan een volle schijf, ongeldige configuratie, beschadigde status of een incompatibele migratie niet oplossen. Waarschuw bij herhaalde herstarts in plaats van deze als geslaagde veerkracht te beschouwen.

Kies het beleid voor workers op basis van wachtrij- en afsluitsemantiek

Een langlopende wachtrij-worker kan unless-stopped gebruiken als deze voortdurend werk moet verwerken. Een eindige worker of batchproces kan on-failure:N gebruiken, zodat tijdelijke fouten een beperkt aantal nieuwe pogingen krijgen terwijl een aanhoudende fout zichtbaar tot stoppen leidt.

Een actuele uitleg over beperkte on-failure-pogingen benadrukt dat het retrygedrag moet aansluiten bij de vraag of een proces permanent actief hoort te zijn of normaal mag eindigen.

Weet wat afsluitcode 0 betekent voor de worker-image. Als dit “taak voltooid” betekent, kan always een geslaagde eenmalige taak in een eindeloze lus veranderen. Als de worker als daemon bedoeld is, kan een onverwachte normale afsluiting toch een automatische herstart via unless-stopped rechtvaardigen.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Houd webapps lang actief, maar laat ze afhangen van echte afhankelijkheden

De meeste zelfgehoste webapplicaties zijn bedoeld om voortdurend beschikbaar te blijven, waardoor unless-stopped doorgaans beter te begrijpen is dan een begrensd beleid dat alleen bij fouten herstart. De herstartinstelling neemt niet weg dat de database, cache, DNS, geheimen en gekoppelde paden gereed moeten zijn.

De gerelateerde ZimaSpace-diagnose over herstartlussen door containerafhankelijkheden laat zien waarom het herhaaldelijk herstarten van de zichtbare app de database-, cache-, mount-, migratie- of geheugenfout die als eerste optrad kan verhullen.

Gebruik waar passend afhankelijkheids-healthchecks voor de startvolgorde en begrens het retrygedrag van de applicatie. Een webservice die elke vijf seconden crasht totdat PostgreSQL start, is minder inzichtelijk dan een service die op gereedheid wacht en één schone start uitvoert.

Geef migraties en eenmalige taken een eindige levenscyclus

Migratiecontainers, importeurs, onderhoudstaken en eenmalige initialisatietaken zijn geen gewone daemons. Hun geslaagde toestand is vaak “afsluiten met code 0 en gestopt blijven”. Het gebruik van always of unless-stopped kan voltooid werk onbedoeld opnieuw uitvoeren.

Houd eenmalige operationele tools expliciet in plaats van ze verborgen altijd-actieve services te laten worden. Een migratie of importeur moet een eindige geslaagde toestand hebben die zichtbaar blijft nadat de opdracht is afgesloten.

Gebruik restart: "no" wanneer een fout moet leiden tot stoppen voor inspectie, of begrensd on-failure alleen wanneer de opdracht veilig opnieuw kan worden uitgevoerd. Controleer bij schemamigraties eerst of het herhalen van een gedeeltelijk uitgevoerde migratie wordt ondersteund voordat je retries automatiseert.

Test het beleid met echte foutscenario’s

Test voor elke service een normale procesafsluiting, een crash met een foutcode, het herstarten van de host, het herstarten van de Docker-daemon, een handmatige stop, een ongezonde maar nog actieve toestand en een onbeschikbare afhankelijkheid. Leg vóór het veerkrachtig noemen van de configuratie de verwachte toestand na elk van deze gebeurtenissen vast.

Houd het aantal herstarts bij en waarschuw wanneer dit binnen een tijdsvenster een kleine drempel overschrijdt. Automatisch herstarten moet de hersteltijd bij tijdelijke fouten verkorten; het mag een aanhoudende crash niet onzichtbaar maken door een eindeloze stroom nieuwe containers te produceren.

Een goed beleidsmatrix is expliciet: langlopende databases en webapps keren terug na infrastructuurherstarts, daemon-workers herstellen volgens de semantiek van de wachtrij, eindige taken stoppen wanneer ze voltooid zijn en gezondheids- en gereedheidscontroles maken fouten zichtbaar die het herstartbeleid niet kan detecteren.