So stimmen Sie Docker-Neustartrichtlinien auf Datenbanken, Worker und Web-Apps ab

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How to Match Docker Restart Policies to Databases, Workers, and Web Apps

Richten Sie Docker-Neustartrichtlinien am Lebenszyklus des Dienstes und an der Exit-Semantik aus, statt jedem Container in einer Compose-Datei unless-stopped zuzuweisen.

Neustartrichtlinien reagieren, wenn der Hauptprozess eines Containers beendet wird; ein Healthcheck kann einen weiterhin laufenden Prozess als fehlerhaft markieren, ohne ihn automatisch neu zu starten. Datenbanken, Worker, Web-Apps, Migrationen und geplante Aufgaben benötigen daher je nach gewünschtem Dauerbetrieb, Bedeutung eines sauberen Beendens und Umgang mit wiederholten Fehlern unterschiedliche Einstellungen.

Trennen Sie Neustartverhalten von Healthchecks und Bereitschaft

Eine Neustartrichtlinie beantwortet die Frage, ob Docker einen Container nach dem Beenden seines Prozesses erneut starten soll. Ein Healthcheck prüft, ob der laufende Dienst eine definierte Operation ausführen kann. Die Bereitschaft von Abhängigkeiten bestimmt, ob ein anderer Dienst bereits starten sollte. Diese Mechanismen lösen verwandte, aber unterschiedliche Probleme.

Ein Healthcheck und Neustart sind getrennt aus dem Jahr 2026 erläutert diese Trennung und zeigt, wie Compose-Health-Bedingungen den Start abhängiger Dienste verzögern können, bis ein Dienst tatsächlich bereit ist.

Erwarten Sie nicht, dass restart: always einen fehlerhaften Webprozess repariert, der nie beendet wird, und erwarten Sie nicht, dass ein Healthcheck allein den Prozess neu startet. Lassen Sie die Anwendung beenden, wenn eine Fortsetzung unsicher ist, fügen Sie einen externen Mechanismus zur Fehlerbehebung hinzu oder lösen Sie entsprechend dem Dienstdesign einen Alarm bei einem fehlerhaften Zustand aus.

Verwenden Sie dauerhafte Neustartrichtlinien für langlebige Datenbanken

Von einer Datenbank auf einem Heimserver wird normalerweise erwartet, dass sie nach einem Neustart des Hosts oder des Docker-Daemons wieder verfügbar ist. unless-stopped ist oft eine praktische Standardeinstellung, wenn ein absichtliches Stoppen durch den Administrator weiterhin berücksichtigt werden soll; always ist geeignet, wenn ein Neustart dieses manuelle Stoppen absichtlich außer Kraft setzen soll.

Eine Neustartrichtlinie folgt dem Prozessende aus dem Juli 2026 beschreibt die Unterschiede zwischen no, on-failure, always und unless-stopped, einschließlich der Tatsache, dass die Richtlinie auf das Prozessende und nicht auf den Health-Status reagiert.

Die Datenbank benötigt außerdem einen echten Healthcheck und dauerhaften Speicher. Wiederholte Neustarts von PostgreSQL können einen vollen Datenträger, eine ungültige Konfiguration, beschädigte Daten oder eine inkompatible Migration nicht beheben. Lösen Sie bei wiederholten Neustarts einen Alarm aus, statt sie als erfolgreiche Ausfallsicherheit zu betrachten.

Wählen Sie die Richtlinie für Worker anhand von Warteschlange und Exit-Semantik

Ein dauerhaft laufender Warteschlangen-Worker kann unless-stopped benötigen, wenn er ständig Aufträge verarbeiten soll. Ein begrenzter Worker oder Batch-Prozess kann on-failure:N verwenden, damit vorübergehende Fehler eine begrenzte Anzahl von Wiederholungen erhalten, während ein dauerhafter Fehler sichtbar zum Anhalten führt.

Ein aktueller Beitrag zu begrenzten on-failure-Wiederholungen betont, dass das Wiederholungsverhalten dazu passen sollte, ob ein Prozess dauerhaft laufen oder normal beendet werden soll.

Verstehen Sie, was der Exit-Code 0 für das Worker-Image bedeutet. Wenn er „Auftrag abgeschlossen“ bedeutet, kann always aus einem erfolgreichen Einmalauftrag eine Endlosschleife machen. Wenn der Worker als Daemon gedacht ist, kann ein unerwartetes sauberes Beenden dennoch einen automatischen Neustart über unless-stopped rechtfertigen.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

Halten Sie Web-Apps dauerhaft am Laufen, aber koppeln Sie sie an echte Abhängigkeiten

Die meisten selbst gehosteten Webanwendungen sollen kontinuierlich verfügbar bleiben, daher ist unless-stopped meist leichter nachvollziehbar als eine begrenzte Richtlinie, die nur auf Fehler reagiert. Die Neustarteinstellung macht es nicht überflüssig, dass Datenbank, Cache, DNS, Geheimnisse und eingebundene Pfade bereit sind.

Die zugehörige ZimaSpace-Diagnose zu Neustartschleifen durch Container-Abhängigkeiten zeigt, warum wiederholte Neustarts der sichtbaren App den zuerst aufgetretenen Fehler in Datenbank, Cache, Mount, Migration oder Speicher verdecken können.

Verwenden Sie, wo angemessen, Healthchecks für Abhängigkeiten zur Steuerung der Startreihenfolge und begrenzen Sie das Wiederholungsverhalten der Anwendung. Ein Webdienst, der alle fünf Sekunden abstürzt, bis PostgreSQL startet, ist schlechter beobachtbar als einer, der auf die Bereitschaft wartet und einen einzigen sauberen Startvorgang ausführt.

Geben Sie Migrationen und Einmalaufträgen einen begrenzten Lebenszyklus

Migrationscontainer, Importeure, Wartungsaufgaben und einmalige Initialisierungsaufträge sind keine gewöhnlichen Daemons. Ihr erfolgreicher Zustand lautet oft „mit Exit 0 beenden und angehalten bleiben“. Die Verwendung von always oder unless-stopped kann abgeschlossene Aufgaben unbeabsichtigt erneut ausführen.

Halten Sie einmalige operative Werkzeuge explizit, statt sie zu versteckten dauerhaft laufenden Diensten werden zu lassen. Eine Migration oder ein Importeur sollte einen begrenzten Erfolgszustand haben, der nach dem Beenden des Befehls sichtbar bleibt.

Verwenden Sie restart: "no", wenn ein Fehler zur Untersuchung anhalten soll, oder on-failure mit Begrenzung nur dann, wenn der Befehl sicher wiederholt werden kann. Prüfen Sie bei Schema-Migrationen, ob das Wiederholen einer teilweise angewendeten Migration unterstützt wird, bevor Sie Wiederholungen automatisieren.

Testen Sie die Richtlinie mit realistischen Fehlerfällen

Testen Sie für jeden Dienst ein sauberes Prozessende, einen Absturz mit einem Wert ungleich null, einen Neustart des Hosts, einen Neustart des Docker-Daemons, ein manuelles Stoppen, einen laufenden, aber fehlerhaften Zustand sowie eine nicht verfügbare Abhängigkeit. Halten Sie den erwarteten Zustand nach jedem Ereignis fest, bevor Sie die Konfiguration als ausfallsicher bezeichnen.

Überwachen Sie die Anzahl der Neustarts und lösen Sie einen Alarm aus, wenn sie innerhalb eines Zeitfensters einen niedrigen Schwellenwert überschreitet. Ein automatischer Neustart sollte die Wiederherstellungszeit bei vorübergehenden Fehlern verkürzen; er sollte einen dauerhaften Absturz nicht unsichtbar machen, indem er eine endlose Folge neuer Container erzeugt.

Eine gute Richtlinienmatrix ist eindeutig: Langlebige Datenbanken und Web-Apps kehren nach Infrastrukturneustarts zurück, Daemon-Worker erholen sich entsprechend der Warteschlangensemantik, begrenzte Aufträge stoppen nach Abschluss, und Health- sowie Bereitschaftsprüfungen machen Fehler sichtbar, die eine Neustartrichtlinie nicht erkennen kann.