Votre application Dockerisée s’arrête-t-elle en toute sécurité ? Liste de contrôle pour la maintenance
Il n’existe pas de réponse universelle à la question de ce qu’il advient du travail en cours quand une application s’arrête. Cette liste vous aide à réunir les bonnes références, à préparer un test limité et à documenter votre procédure de maintenance.
Une procédure d’arrêt dépend de votre application
Le redémarrage d’une application ne suffit pas à déterminer ce qu’il est advenu des requêtes, des tâches ou des modifications en cours. Les réponses dépendent de l’application et de sa configuration : cette liste ne prescrit donc ni commande universelle ni garantie de fermeture propre.
Pour les notions propres à Docker, commencez par la [documentation officielle de Docker](https://docs.docker.com/). Pour établir le comportement de votre service, réunissez aussi les références de l’application, de l’image utilisée et de votre configuration de déploiement. Une documentation générale ne remplace pas ces consignes propres à votre installation.
- Notez le nom et la version de l’application, l’image déployée et la configuration concernée.
- Ajoutez à votre fiche de maintenance les URL exactes des documents officiels que vous avez consultés.
- Si une réponse essentielle manque dans ces documents, demandez-la au responsable de l’application ou à votre hébergeur avant de planifier une opération risquée.
Définissez ce que la maintenance doit protéger
Avant de chercher des réglages, listez les usages qui comptent pour votre activité. Distinguez les actions qui modifient des données des pages qui peuvent simplement être consultées de nouveau.
Pour chaque usage important, formulez une question précise à résoudre à partir de la documentation ou avec le responsable du produit : que faut-il vérifier si l’action est interrompue ou si son résultat est incertain ?
- Choisissez quelques parcours représentatifs, par exemple l’enregistrement d’une fiche, l’envoi d’un formulaire ou le téléversement d’un fichier, s’ils existent dans votre application.
- Ajoutez les traitements en arrière-plan dont dépend votre activité, comme des tâches planifiées ou des importations.
- Pour chaque parcours, notez où vérifier son résultat et dans quelles conditions une nouvelle tentative est appropriée, si la documentation le précise.
Relevez les paramètres et réponses documentés
Dans les documents officiels correspondant à votre version, recherchez les consignes d’arrêt et les paramètres pertinents du déploiement. Consignez ce que les sources disent, sans extrapoler à partir d’une autre application ou d’une configuration différente.
Utilisez une fiche courte pour séparer les informations vérifiées des questions ouvertes. Cela évite de transformer une hypothèse sur un signal, un délai ou une tâche en consigne d’exploitation.
- Référence consultée et version à laquelle elle s’applique.
- Signal et délai configurés, si les documents ou les paramètres réels les indiquent.
- Comportement documenté des requêtes et des tâches interrompues, ou mention explicite que la réponse reste à confirmer.
- Procédure de remplacement ou de maintenance effectivement prévue pour votre déploiement.
N’essayez pas une procédure risquée directement en production
Un test ne répond qu’aux questions qu’il permet réellement d’observer. N’effectuez pas d’essai d’interruption en production si cela peut affecter des utilisateurs, modifier des données ou déclencher des effets externes.
Si les consignes de l’application et votre environnement autorisent un essai hors production, définissez d’abord ce que vous allez vérifier et comment vous pourrez revenir à un état acceptable. En l’absence d’une procédure documentée ou d’un moyen de contrôler les effets, demandez conseil plutôt que d’improviser.
- Utilisez un environnement de test et des données que vous pouvez supprimer, lorsque cela convient à votre application.
- Notez à l’avance le résultat attendu et les éléments qui permettront de le vérifier.
- Suivez uniquement une procédure compatible avec la documentation de l’application et votre déploiement.
- Consignez les observations et les incertitudes ; ne généralisez pas un essai à une autre version ou configuration.
Transformez les réponses en procédure de maintenance
Rédigez une procédure concise à partir des éléments vérifiés : contrôles avant l’opération, consignes documentées à suivre, vérifications après le remplacement et personne chargée de décider si le service peut être utilisé de nouveau.
Traitez séparément les sauvegardes et les opérations interrompues. Documentez les données couvertes, le calendrier configuré et la manière dont une restauration serait vérifiée ; ces éléments ne déterminent pas, à eux seuls, le résultat d’une requête ou d’une tâche interrompue.
- Indiquez les responsabilités, les vérifications après maintenance et la personne à contacter en cas de problème.
- Lorsque cela convient, informez les utilisateurs de la maintenance et de la marche à suivre si le résultat d’une action est incertain.
- Réexaminez la procédure lorsque l’application, l’image ou le déploiement change.
- Avec un hébergement géré, faites préciser les tâches prises en charge par le fournisseur et celles qui restent de votre ressort, notamment pour les données, les accès et la récupération.
Ce que l’hébergement géré change — et ne change pas
Airbip propose le déploiement géré d’applications professionnelles, de publication, d’analyse, de collaboration et d’IA. Les instances d’applications s’exécutent sous forme de charges de travail Docker sur les serveurs cloud d’Airbip. Airbip fournit également la gestion du cycle de vie des services ainsi que des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables.
Ces fonctionnalités d’infrastructure ne précisent pas le comportement à l’arrêt d’une application donnée. Pour votre plan de maintenance, appuyez-vous sur les références de cette application et clarifiez le périmètre des sauvegardes ainsi que la répartition des responsabilités.
- Vérifiez les consignes propres à l’application, plutôt que de déduire son comportement des fonctions d’hébergement.
- Confirmez les limites du service géré et les responsabilités de récupération avant de vous fier à une procédure.
- Choisissez un modèle de déploiement adapté à vos besoins de contrôle, de soutien opérationnel et de planification de la récupération.
Questions fréquentes
Un redémarrage réussi prouve-t-il que l’arrêt s’est déroulé en toute sécurité ?
Non. Il ne suffit pas à établir le résultat des requêtes, des tâches ou des modifications de données en cours. Consultez les consignes correspondant à votre application et vérifiez les opérations importantes séparément.
Où trouver les consignes pertinentes pour mon déploiement ?
Consultez la documentation officielle de l’application et de l’image utilisées, ainsi que les paramètres et documents de votre déploiement. La [documentation Docker](https://docs.docker.com/) est une référence pour les sujets Docker, mais ne remplace pas les consignes propres à votre application.
Quelle durée choisir pour le délai d’arrêt ?
Cette liste ne fixe pas de valeur universelle. Relevez le délai configuré et cherchez dans les documents de votre application et de votre déploiement ce qui s’applique à la procédure prévue. Si la réponse manque, faites-la confirmer avant la maintenance.
Comment tester le comportement à l’arrêt ?
Ne testez pas en production si l’interruption risque d’affecter des utilisateurs, des données ou des services externes. Un essai hors production n’est à envisager que si les consignes et votre environnement le permettent, avec un résultat attendu et un moyen de vérifier les effets définis à l’avance.
Les sauvegardes prouvent-elles qu’une tâche interrompue a été traitée correctement ?
Non. Les sauvegardes concernent la récupération des données. Vérifiez séparément leur périmètre et les consignes de l’application pour les requêtes et les tâches interrompues.
Sources et lectures complémentaires
- Docker documentation — Docker
- Traefik documentation — Traefik Labs
- Let’s Encrypt documentation — Internet Security Research Group