Vos données d’application survivront-elles à la recréation d’un conteneur ? Liste de vérification Docker

Pourquoi le remplacement d’un conteneur est important

Un conteneur peut être arrêté puis redémarré, ou supprimé et remplacé lors d’une modification du déploiement. Il s’agit de deux événements distincts du cycle de vie : un redémarrage réussi ne prouve donc pas que les données importantes de l’application survivront au remplacement. La documentation de démarrage de Docker traite la persistance des données comme un concept à part entière (documentation Docker : https://docs.docker.com/get-started/docker-concepts/running-containers/persisting-container-data/).

La couche inscriptible d’un conteneur arrêté reste disponible jusqu’à la suppression de ce conteneur ; le redémarrage du même conteneur la réactive (Dash0, « How to Preserve Data When a Docker Container Exits » : https://www.dash0.com/faq/how-to-preserve-data-when-a-docker-container-exits). Cela ne permet pas de savoir ce qu’il advient des données lors de la suppression et du remplacement. Testez l’événement du cycle de vie qui vous concerne réellement.

• Précisez le changement que vous voulez tester : redémarrage, mise à jour, suppression et recréation, ou autre action gérée par le fournisseur.
• Pour un premier test, utilisez un environnement hors production ou des données que vous pouvez perdre sans risque.
• Si vous ne savez pas si un changement réutilise ou remplace le conteneur, demandez à la personne qui gère le déploiement.

Repérer les données, la configuration et les emplacements de stockage

Dressez un bref inventaire de ce que l’application crée ou utilise, par exemple des données liées à la base de données, des fichiers téléversés par les utilisateurs, la configuration, des fichiers générés ou des journaux. Ce sont des catégories à examiner, et non l’affirmation que toutes les applications stockent ces éléments de la même façon.

Pour chaque élément, notez où l’application ou le déploiement indique qu’il se trouve : dans le conteneur, sur un point de montage configuré, dans un autre service ou dans la configuration du déploiement. Signalez comme inconnue toute information que vous ne pouvez pas vérifier. Vérifiez les chemins propres à l’application et son comportement à l’initialisation dans la documentation de déploiement de cette application.

Pour chaque point de montage configuré, consignez son type, sa source et sa destination telles qu’elles apparaissent dans le déploiement, son objectif prévu et le comportement documenté lors de la procédure de remplacement. Le nom d’un point de montage ne permet pas, à lui seul, de savoir ce qu’il contient ni si la procédure le préservera.

• Donnée ou paramètre : de quoi s’agit-il et quelles seraient les conséquences de sa disparition ?
• Emplacement et éléments à l’appui : où l’application ou le déploiement indique-t-il que cet élément se trouve, et quelles instructions ou quels paramètres le confirment ?
• Cycle de vie : que devrait-il advenir de cet emplacement lors du changement que vous prévoyez de tester ?
• Inconnues : que faut-il confirmer avant une modification en production ?

Vérifier les instructions de déploiement avant le test

Consultez la documentation officielle de déploiement du fournisseur de l’application pour repérer les chemins de données requis, les paramètres de configuration et le comportement à la première exécution ou à l’initialisation. Comparez ces instructions à la définition réelle du déploiement ; ne copiez pas un chemin provenant d’une autre installation et ne supposez pas qu’un conteneur vierge traitera correctement les données existantes.

Si un chemin requis n’est pas configuré, si une étape d’initialisation n’est pas claire ou si le déploiement ne correspond pas aux instructions, faites une pause et demandez des précisions avant tout test avec des données importantes. Consignez la documentation et les paramètres vérifiés afin que vos attentes correspondent au déploiement réellement utilisé.

• Quels chemins documentés contiennent des données d’état ou des données utilisateur, et le déploiement prévoit-il un stockage pour ces chemins ?
• Que dit la documentation de l’application sur le comportement à la première exécution ou sur un chemin qui contient déjà des données ?
• Selon la documentation, comment la configuration est-elle fournie dans cette installation ?
• Quels paramètres ou détails du cycle de vie restent à vérifier ?

Effectuer un test contrôlé de persistance

Testez précisément l’événement du cycle de vie qui vous préoccupe, avec des données que vous pouvez perdre sans risque. Privilégiez un environnement hors production. Si un test sur un service en activité est nécessaire, obtenez une autorisation et utilisez un élément à faible risque, identifiable et supprimable par la suite.

Créez dans l’application un élément de test portant un nom explicite et notez comment le reconnaître. Suivez la procédure de remplacement documentée — et non un simple arrêt-redémarrage si votre préoccupation porte sur la suppression et la recréation. Ensuite, vérifiez si l’élément est présent et utilisable, puis contrôlez séparément les autres données inventoriées qui comptent.

Consignez le résultat et toute hypothèse modifiée. Un test concluant ne vaut que pour ce déploiement et cette procédure ; il ne permet pas d’établir le comportement de chaque catégorie de données ni celui d’un autre scénario de récupération.

• Avant : consignez l’application, le déploiement, l’élément de test et l’action du cycle de vie.
• Après : vérifiez l’élément de test et toute autre catégorie de données importante.
• Documentez : notez la procédure, le résultat, les données manquantes ou modifiées et les questions qui restent en suspens.
• Nettoyez : supprimez l’élément de test si cela convient et confirmez que l’application est dans l’état prévu.

Distinguer la persistance, les sauvegardes et les responsabilités

La persistance et la sauvegarde répondent à des questions différentes. Le fait qu’un emplacement reste disponible au cours d’une procédure de remplacement ne permet pas de savoir si les données peuvent être récupérées après une perte ou une erreur. Documentez séparément les données à sauvegarder, le contenu couvert par une sauvegarde, le fonctionnement de la récupération et la personne responsable de chaque étape.

Déterminez également qui peut accéder à l’application, à sa configuration de stockage et à tout mécanisme de récupération. Ne supposez pas que le mode d’hébergement détermine quelles données sont couvertes, combien de temps elles sont conservées ni qui peut les restaurer.

Airbip propose des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Les informations produit disponibles ne précisent pas quelles données d’application sont incluses dans chaque sauvegarde ni quelle est la procédure de récupération ; confirmez ces détails en fonction de vos besoins.

• Déterminez quelles données doivent pouvoir être récupérées et qui confirme la couverture des sauvegardes.
• Demandez ce que les sauvegardes incluent et excluent, ainsi que la façon dont la récupération est demandée et effectuée.
• Confirmez qui peut accéder aux données de l’application ou les administrer, ainsi qu’aux paramètres de déploiement.
• Ne confondez pas les attentes en matière de sauvegarde et de récupération avec le résultat du test de persistance.

Questions à poser à un fournisseur d’hébergement géré

Demandez des réponses adaptées au déploiement de votre application et à l’événement précis du cycle de vie qui vous préoccupe, plutôt que de vous fier à des assurances générales. Utilisez les réponses pour déterminer si le modèle géré correspond à vos exigences en matière de données, d’accès et de gouvernance.

Airbip exécute les instances d’applications sous forme de charges de travail Docker sur ses serveurs cloud et assure la gestion du cycle de vie des services. La plateforme automatise le routage et les certificats TLS avec Traefik et Let’s Encrypt, et propose des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Ces capacités ne précisent pas, à elles seules, quels chemins d’application persistent lors d’un remplacement ni ce qu’inclut une sauvegarde.

Si un fournisseur ne peut pas clarifier les détails de déploiement que vous devez maîtriser, ou si son service ne répond pas à vos exigences de gouvernance, évaluez un modèle de déploiement qui vous donne le contrôle nécessaire.

• Quelle action précise constitue un remplacement de conteneur pour mon instance, et quels emplacements de données et de configuration sont conservés lors de cette opération ?
• Sur quoi repose cette réponse, et où puis-je consulter les paramètres de stockage propres à l’application ?
• Que comprennent les sauvegardes, comment fonctionne la récupération et qui est responsable de chaque étape ?
• Quels contrôles d’accès s’appliquent, et quels changements ou actions restent sous ma responsabilité ?