Comment adapter les politiques de redémarrage Docker aux bases de données, aux workers et aux applications web

Adaptez les politiques de redémarrage Docker au cycle de vie du service et à la sémantique de sortie, plutôt que d’attribuer unless-stopped à chaque conteneur d’un fichier Compose.

Les politiques de redémarrage réagissent lorsque le processus principal d’un conteneur se termine ; une vérification d’état peut signaler qu’un processus toujours en cours n’est pas sain sans le redémarrer automatiquement. Les bases de données, les workers, les applications web, les migrations et les tâches planifiées nécessitent donc des choix différents selon qu’elles sont censées rester actives, la signification d’une sortie normale et la manière dont les échecs répétés doivent être signalés.

Séparez le comportement de redémarrage de l’état de santé et de la disponibilité

Une politique de redémarrage indique si Docker doit relancer un conteneur après l’arrêt de son processus. Une vérification d’état indique si le service en cours d’exécution peut effectuer une opération définie. La disponibilité des dépendances indique si un autre service doit encore attendre avant de démarrer. Ces mécanismes répondent à des problèmes liés, mais différents.

Un article de 2026 intitulé l’état de santé et le redémarrage sont distincts explique cette séparation et montre comment les conditions d’état de Compose peuvent retarder le démarrage d’un service dépendant jusqu’à ce qu’un service soit réellement prêt.

Ne vous attendez pas à ce que restart: always répare un processus web défaillant qui ne se termine jamais, et n’attendez pas non plus d’une simple vérification d’état qu’elle le redémarre. Faites quitter l’application lorsque continuer est dangereux, ajoutez un mécanisme de correction externe ou déclenchez une alerte lorsque l’état est défaillant, selon la conception du service.

Utilisez des politiques de redémarrage persistantes pour les bases de données à long terme

Une base de données sur un serveur domestique est généralement censée revenir après le redémarrage de l’hôte ou du démon Docker. unless-stopped constitue souvent une valeur par défaut pratique lorsqu’un arrêt volontaire par l’administrateur doit rester respecté ; always convient lorsque le redémarrage doit, par conception, annuler cet état d’arrêt manuel.

Un article de juillet 2026 intitulé une politique de redémarrage suit la sortie du processus détaille les différences entre no, on-failure, always et unless-stopped, notamment le fait que la politique réagit à la sortie du processus et non à son état de santé.

La base de données a également besoin d’une véritable vérification d’état et d’un stockage durable. Redémarrer PostgreSQL en boucle ne peut pas résoudre un disque plein, une configuration invalide, un état corrompu ou une migration incompatible. Déclenchez une alerte en cas de redémarrages répétés au lieu de les considérer comme une résilience réussie.

Choisissez la politique des workers selon la file d’attente et la sémantique de sortie

Un worker de file d’attente fonctionnant en continu peut justifier unless-stopped s’il doit toujours consommer les tâches. Un worker fini ou un processus de traitement par lots peut utiliser on-failure:N afin d’accorder un nombre limité de nouvelles tentatives aux erreurs temporaires, tandis qu’un échec persistant arrête visiblement le service.

Un article récent intitulé des tentatives limitées avec on-failure souligne que le comportement en cas de nouvelle tentative doit correspondre au fait qu’un processus est censé rester actif en permanence ou pouvoir se terminer normalement.

Sachez ce que signifie le code de sortie 0 pour l’image du worker. S’il signifie « tâche terminée », always peut transformer une tâche exécutée une seule fois avec succès en boucle infinie. Si le worker est conçu comme un démon, une sortie normale inattendue peut malgré tout justifier un redémarrage automatique via unless-stopped.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Gardez les applications web actives en continu, mais conditionnez leur démarrage à leurs véritables dépendances

La plupart des applications web auto-hébergées sont conçues pour rester disponibles en permanence. unless-stopped est donc généralement plus facile à comprendre qu’une politique limitée aux échecs. Le paramètre de redémarrage ne dispense pas de vérifier que la base de données, le cache, le DNS, les secrets et les chemins montés sont prêts.

Le diagnostic ZimaSpace associé sur les boucles de redémarrage dues aux dépendances des conteneurs montre pourquoi redémarrer sans cesse l’application visible peut masquer l’échec initial de la base de données, du cache, du montage, de la migration ou de la mémoire.

Utilisez des vérifications d’état des dépendances pour ordonner le démarrage lorsque cela est approprié et limitez le comportement de nouvelle tentative de l’application. Un service web qui plante toutes les cinq secondes jusqu’au démarrage de PostgreSQL est moins observable qu’un service qui attend la disponibilité et produit un démarrage propre unique.

Donnez aux migrations et aux tâches ponctuelles un cycle de vie limité

Les conteneurs de migration, les importateurs, les tâches de maintenance et les tâches d’initialisation ponctuelles ne sont pas des démons ordinaires. Leur état de réussite est souvent « quitter avec le code 0 et rester arrêté ». Utiliser always ou unless-stopped peut relancer involontairement une tâche déjà terminée.

Gardez les outils opérationnels ponctuels explicites au lieu de les laisser devenir des services toujours actifs dissimulés. Une migration ou un importateur doit avoir un état de réussite fini, qui reste visible après la fin de la commande.

Utilisez restart: "no" lorsque l’échec doit entraîner un arrêt pour inspection, ou on-failure avec un nombre limité de tentatives uniquement lorsque la commande peut être relancée sans danger. Pour les migrations de schéma, vérifiez d’abord qu’une migration partiellement appliquée peut être répétée avant d’automatiser les nouvelles tentatives.

Testez la politique avec de véritables modes de défaillance

Pour chaque service, testez une sortie normale du processus, un plantage avec code différent de zéro, le redémarrage de l’hôte, le redémarrage du démon Docker, l’arrêt manuel, une condition où le service est défaillant mais toujours en cours d’exécution et l’indisponibilité d’une dépendance. Notez l’état attendu après chaque événement avant de considérer la configuration comme résiliente.

Suivez le nombre de redémarrages et déclenchez une alerte lorsqu’il dépasse un seuil peu élevé sur une période donnée. Le redémarrage automatique doit réduire le temps de récupération après une défaillance temporaire ; il ne doit pas rendre un plantage persistant invisible en produisant une série infinie de nouveaux conteneurs.

Une bonne matrice de politiques est explicite : les bases de données et applications web à long terme reviennent après les redémarrages de l’infrastructure, les workers fonctionnant comme des démons récupèrent selon la sémantique de la file d’attente, les tâches finies s’arrêtent une fois terminées et les vérifications d’état et de disponibilité exposent les défaillances que la politique de redémarrage ne peut pas détecter.