Så matchar du Dockers omstartspolicyer med databaser, arbetare och webbappar

Matcha Dockers omstartspolicyer med tjänstens livscykel och avslutssemantik i stället för att tilldela unless-stopped till varje container i en Compose-fil.

Omstartspolicyer reagerar när en containers huvudprocess avslutas; en hälsokontroll kan markera en fortfarande körande process som ohälsosam utan att automatiskt starta om den. Databaser, arbetare, webbappar, migreringar och schemalagda jobb behöver därför olika val beroende på om de ska fortsätta vara aktiva, vad ett rent avslut innebär och hur upprepade fel ska synliggöras.

Håll isär omstartsbeteende från hälsa och beredskap

En omstartspolicy anger om Docker ska starta en container igen efter att processen har stoppats. En hälsokontroll anger om den körande tjänsten kan utföra en definierad åtgärd. Beroendeberedskap anger om en annan tjänst ska starta ännu. De löser relaterade men olika problem.

En hälsokontroll och omstart är separata från 2026 förklarar denna åtskillnad och visar hur Compose-hälsovillkor kan fördröja starten av beroende tjänster tills en tjänst faktiskt är redo.

Förvänta dig inte att restart: always ska reparera en ohälsosam webbprocess som aldrig avslutas, och förvänta dig inte heller att en hälsokontroll ensam ska starta om den. Låt programmet avslutas när det är osäkert att fortsätta, lägg till en extern åtgärdsmekanism eller larma vid ohälsosamt tillstånd utifrån tjänstens utformning.

Använd beständiga omstartspolicyer för långlivade databaser

En databas på en hemmaserver förväntas normalt återgå efter en omstart av värddatorn eller Docker-daemonen. unless-stopped är ofta ett praktiskt standardval när ett avsiktligt administratörsstopp ska respekteras; always passar när omstarten enligt design ska åsidosätta det manuella stoppet.

En omstartspolicy följer processens avslut från juli 2026 beskriver skillnaden mellan no, on-failure, always och unless-stopped, inklusive att policyn reagerar på processens avslut i stället för hälsostatus.

Databasen behöver också en riktig hälsokontroll och beständig lagring. Att starta om PostgreSQL upprepade gånger kan inte åtgärda en full disk, ogiltig konfiguration, skadat tillstånd eller en inkompatibel migrering. Larma vid upprepade omstarter i stället för att betrakta dem som lyckad motståndskraft.

Välj arbetarpolicy utifrån kö- och avslutssemantik

En långkörande köarbetare kan behöva unless-stopped om den alltid ska konsumera arbete. En ändlig arbetare eller batchprocess kan använda on-failure:N så att tillfälliga fel får ett begränsat antal försök medan ett bestående fel stoppas tydligt.

En aktuell begränsad antal omförsök vid fel betonar att omförsöksbeteendet bör motsvara om processen ska vara permanent aktiv eller tillåtas avslutas normalt.

Ta reda på vad avslutskod 0 betyder för arbetaravbildningen. Om den betyder ”jobbet är klart” kan always förvandla ett lyckat engångsjobb till en oändlig loop. Om arbetaren ska fungera som en daemon kan ett oväntat rent avslut ändå motivera en automatisk återstart genom unless-stopped.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Håll webbappar långlivade men villkora dem mot verkliga beroenden

De flesta självvärdade webbapplikationer är avsedda att vara tillgängliga kontinuerligt, så unless-stopped är vanligtvis enklare att resonera kring än en begränsad policy som bara gäller vid fel. Omstartsinställningen eliminerar inte behovet av att databas, cache, DNS, hemligheter och monterade sökvägar är redo.

Den relaterade ZimaSpace-diagnostiken om omstartsslingor orsakade av containerberoenden visar varför upprepade omstarter av den synliga appen kan dölja databas-, cache-, monterings-, migrerings- eller minnesfelet som inträffade först.

Använd beroendehälsokontroller för startordning där det passar och begränsa programmets återförsöksbeteende. En webbtjänst som kraschar var femte sekund tills PostgreSQL startar är mindre observerbar än en som väntar på beredskap och genomför en ren uppstart.

Ge migreringar och engångsjobb en begränsad livscykel

Migreringscontainrar, importverktyg, underhållsuppgifter och engångsjobb för initiering är inte vanliga daemons. Deras lyckade tillstånd är ofta ”avsluta med kod 0 och förbli stoppade”. Att använda always eller unless-stopped kan oavsiktligt köra färdigt arbete igen.

Håll operativa engångsverktyg explicita i stället för att låta dem bli dolda tjänster som alltid körs. En migrering eller import bör ha ett begränsat lyckat tillstånd som förblir synligt efter att kommandot avslutats.

Använd restart: "no" när ett fel ska stoppa processen för inspektion, eller begränsad on-failure endast när kommandot är säkert att köra igen. För schemamigreringar ska du säkerställa att en delvis genomförd migrering kan upprepas innan du automatiserar omförsök.

Testa policyn med verkliga felscenarier

Testa för varje tjänst ett rent processavslut, en krasch med felkod, omstart av värddatorn, omstart av Docker-daemonen, manuellt stopp, ett ohälsosamt men fortfarande körande tillstånd samt ett otillgängligt beroende. Dokumentera det förväntade tillståndet efter varje händelse innan du kallar konfigurationen motståndskraftig.

Följ omstartsantalet och larma när det överskrider en låg tröskel inom ett tidsintervall. Automatisk omstart bör minska återställningstiden vid tillfälliga fel; den ska inte göra en bestående krasch osynlig genom att skapa en oändlig ström av nya containrar.

En bra policymatris är tydlig: långlivade databaser och webbappar återgår efter infrastrukturstarter, daemonarbetare återhämtar sig enligt kösemantiken, ändliga jobb stoppas när de är klara och hälso- och beredskapskontroller synliggör fel som omstartspolicyn inte kan upptäcka.