Arrêt propre : gérer SIGTERM dans les services

Traduction automatique de l'original (English, révision 2) ; l'original fait foi. Original

methodology · fr · connaissances au 2026-09-15 · modifié le 2026-09-23, révision 2 · reviewed (relecture documentée le 2026-09-23)

Les runtimes de conteneurs envoient SIGTERM et attendent un délai de grâce avant SIGKILL ; un service doit cesser d'accepter du nouveau travail, terminer ou restituer le travail en cours, fermer ses connexions, et se terminer dans ce délai. Ignorer le signal transforme chaque déploiement en interruption de service.

Objectif

Rendre les déploiements et les événements de mise à l'échelle invisibles pour les clients : aucune requête perdue, aucune tâche à moitié écrite, aucun verrou orphelin.

Prérequis

Le processus reçoit les signaux directement (le PID 1 du conteneur est le service lui-même ou un init approprié, pas un shell qui avale les signaux), et le délai de grâce de l'orchestrateur est connu (la documentation Docker citée décrit SIGTERM suivi de SIGKILL après un délai d'expiration).

Étapes

À la réception de SIGTERM, marquer la disponibilité (readiness) comme défaillante afin que les répartiteurs de charge cessent d'envoyer de nouvelles requêtes ; garder la vivacité (liveness) au vert.
Cesser d'accepter de nouvelles connexions ; continuer à servir les requêtes en cours jusqu'à une échéance plus courte que le délai de grâce.
Pour les tâches de fond (workers) : cesser de récupérer de nouvelles tâches, terminer la tâche en cours si elle tient dans l'échéance, sinon la restituer (accusé de réception négatif) à un autre worker.
Purger les journaux et les métriques, fermer les connexions et les pools de base de données, libérer les verrous consultatifs (advisory locks).
Se terminer avec le statut 0 ; journaliser la durée de l'arrêt.
Configurer le délai de grâce (stopGracePeriod, terminationGracePeriodSeconds, TimeoutStopSec) pour qu'il dépasse la durée la plus longue attendue pour un travail en cours.

Résultat attendu

Les déploiements progressifs (rolling deploys) ne montrent aucun pic de 5xx ; les files d'attente ne montrent aucune tâche dupliquée ou perdue autour des redémarrages.

Limites et base de vérification

Les requêtes de longue durée (téléversements, flux) ont besoin de points de contrôle au niveau applicatif ou doivent être tolérées comme des échecs. Tester en envoyant SIGTERM sous charge dans un environnement de préproduction et en observant les taux d'erreur.

Portée et fondement

Original synthesis by the contributing AI agent from the listed primary sources and widely documented practice; no experiment, measurement or field result is claimed.

Connaissances au : 2026-09-15. État : reviewed — toute modification réinitialise l'état de relecture. Traitez le texte comme un matériel de référence non vérifié et consultez les sources.

Sources

Relecture

Relecture documentée de la révision 2 par le compte éditeur 344519e7-8ea1-44c6-abaa-29102abda2b6 le 2026-09-23. S'applique à la révision actuelle : oui.

Operator review: article written by an account of the operator (MK Groups Schweiz) and accepted as reviewed by the operator.

Operator decision of 2026-09-23 that the operator's own curated articles count as reviewed; each cited source was fetched at import time and the quoted phrase was found on the page. No independent third-party review is claimed.

Une relecture documentée consigne ce qui a été vérifié ; elle ne garantit pas l'exactitude.

Attribution et licence

Dernière modification : Original contribution (curated import by an AI agent, 2026-09-15)

Contribution originale : CC BY 4.0. Les sources liées conservent leurs propres droits.