Logs, arrêt propre et retour de version

Comprendre le mécanisme

Une application conteneurisée doit exposer des journaux utiles et un comportement d’arrêt défini. La commande principale et la forme de lancement influencent la propagation des signaux. À l’arrêt, terminez ou annulez proprement le travail en cours dans un délai borné. Un redémarrage automatique peut aider à la disponibilité, sans résoudre une erreur de configuration ou une corruption répétée.

Raisonner et vérifier

La vérification de santé doit tester un contrat significatif sans divulguer de secret. Corrélez image exécutée, révision et événements métier minimisés. Pour revenir à une version précédente, utilisez un artefact identifié et vérifiez sa compatibilité avec les données et migrations. Une procédure n’est fiable qu’après exercice dans un environnement contrôlé ; documentez aussi le délai de retour et les limites.

Une identité de release retrouvable

Une release doit relier source, tests et contenu exécuté. Un tag mutable seul ne permet pas de retrouver exactement ce qui a été servi à une date donnée. Conservez les références pertinentes et vérifiez l’identité active après bascule. Cette preuve aide à distinguer un défaut du nouveau code d’un processus resté sur l’ancien artefact ou d’une configuration différente.

Les logs sont un stockage à contrôler

Collecter stdout ne rend pas chaque donnée appropriée à une conservation ou un partage. Les traces peuvent contenir tokens, corps personnels et chemins sensibles. Définissez champs, accès et durée selon le besoin d’exploitation. Un incident doit être corrélable par des éléments minimisés. Les diagnostics d’échec demandent une attention particulière car ils traversent parfois des chemins moins contrôlés que les réponses nominales.

Arrêt gracieux et travail en cours

Un arrêt propre possède un délai et un contrat sur les tâches commencées. Transmettre un signal ne garantit pas l’annulation d’une mutation distante déjà validée. Le service doit savoir ce qu’il termine, reporte ou réconcilie. Testez l’arrêt pendant une opération de laboratoire et observez effets, files et redémarrage. Un processus arrêté rapidement n’est pas forcément un état métier correctement repris.

Le retour d’image ne rembobine pas les volumes

Revenir à une ancienne image modifie le code exécuté, pas automatiquement les écritures persistantes. Les volumes et bases peuvent conserver un format nouveau ou un effet déjà appliqué. Une procédure de rollback doit donc analyser la compatibilité avec l’état courant et les mécanismes de reprise. L’existence d’un ancien artefact ne démontre pas que sa réexécution est sûre sur toutes les données récentes.

Prouver la sauvegarde par une restauration

Une archive doit être restaurée dans un environnement distinct avec les outils et préconditions nécessaires. Vérifiez un parcours fonctionnel et les invariants utiles après récupération. Mesurez le délai sur un volume représentatif et conservez les limites. Un redémarrage automatique ou une réplication active ne protège pas nécessairement contre une suppression logique qui a déjà été propagée.

Tester le bon endpoint de santé

Un résultat 200 sur une page statique ne prouve pas que l’application, sa base et la release attendue fonctionnent ensemble. Le contrôle doit porter sur une garantie précise et bornée. Conservez l’identité de version avec la réponse utile, sans publier de secrets. Le succès décrit ce parcours observé ; il ne remplace pas une suite d’autorisation ni une restauration de secours.

Renouveler les processus avec le contenu

Modifier un tag dans un registre ne transforme pas automatiquement les conteneurs déjà actifs. La procédure doit récupérer la bonne référence et remplacer ou renouveler les instances selon le modèle choisi. Vérifiez ensuite le contenu réellement servi. Une simple copie de fichiers ou modification de configuration ne prouve pas que chaque processus a chargé l’état prévu.

Coordonner la migration de données

Une migration peut rendre une ancienne version incompatible avec le schéma courant. Définissez les phases compatibles et les critères qui autorisent le retrait de l’ancien contrat. Avant rollback, examinez cette situation avec les nouvelles écritures déjà effectuées. Un exercice doit simuler la panne à un point intermédiaire, car une démonstration sur une base vide ne couvre pas les données de production.

Surveiller la capacité et les boucles de reprise

Un état running n’assure pas une capacité suffisante ni une configuration correcte. Le processus peut être saturé ou répéter le même échec après chaque redémarrage. Reliez ressources, files, délais et résultats métier dans le diagnostic. La reprise automatique doit être bornée et observable ; elle ne constitue pas une correction d’un défaut permanent de configuration ou de donnée.

Conserver un dossier d’incident utile

Les preuves d’exercice doivent préciser actif, version, chronologie, observations et limites sans publier les credentials réels. Chaque action doit avoir une raison et un résultat vérifiable. Notez les risques résiduels et les étapes qui n’ont pas été testées. Ce dossier permet d’améliorer la procédure après l’incident, au lieu de conclure que tout est restaurable parce qu’une seule commande a terminé sans erreur.

Atelier guidé : lire, expliquer et vérifier le code

# Plan proposé :
# 1. Déployer lab-api:2 et migrer la base.
# 2. En cas d’erreur, relancer lab-api:1.
# Aucune procédure de données n’est définie.

Le plan de l’atelier revient au code précédent après une migration annoncée comme incompatible. Cette seule action ne restaure ni schéma ni données. L’ancien binaire peut donc démarrer puis échouer ou mal interpréter l’état courant. Le défaut n’est pas le nom du tag ou celui du conteneur, mais l’absence d’une stratégie de compatibilité et de reprise de la couche persistante.

Préparez un jeu de données de laboratoire puis exercez les deux versions autour d’une migration contrôlée. Notez le point où le retour direct cesse d’être valable et quelles opérations supplémentaires sont nécessaires. Une stratégie progressive peut limiter cette fenêtre, mais elle doit être démontrée. Le contrôle de santé final doit confirmer une réponse applicative attendue liée à la version réellement active.