Volumes, montages et sauvegardes cohérentes

Comprendre le mécanisme

Un volume géré par Docker persiste indépendamment d’une instance donnée selon son cycle de vie. Un bind mount expose un chemin de l’hôte et lie davantage le conteneur à cet environnement. Monter un volume au-dessus d’un répertoire existant masque le contenu visible sous ce point de montage. La persistance n’est pas une sauvegarde : suppression, corruption ou erreur métier peuvent affecter les données durables.

Raisonner et vérifier

Pour une base active, copier des fichiers à un moment arbitraire n’est pas forcément une sauvegarde cohérente. Utilisez une procédure supportée par le moteur ou un instantané cohérent selon son contrat. Testez la restauration dans une instance et un volume séparés. Les options de lecture seule et permissions limitent certains accès, sans remplacer le choix du propriétaire des données et les droits du processus.

Le stockage possède son propre cycle de vie

Un volume peut survivre au remplacement d’un conteneur selon sa configuration et les opérations effectuées. Cette persistance permet de séparer les données de l’instance, mais ne promet pas une survie à toute suppression ou perte d’hôte. Définissez qui possède le volume, comment il est conservé et comment il est restauré. Un test doit remplacer réellement l’instance tout en vérifiant les données attendues.

Le bind mount dépend du chemin hôte

Un bind mount relie un emplacement de l’hôte à une vue dans le conteneur. Sa disponibilité et ses permissions dépendent donc aussi de cet hôte. Un chemin existant sur le poste peut manquer sur le serveur ou contenir un autre contenu. Documentez la source et la destination, puis testez l’environnement cible proprement au lieu de déduire la portabilité depuis une exécution locale confortable.

Persistance et sauvegarde sont deux capacités

Un volume conservé n’est pas automatiquement une copie indépendante et restaurable. Il peut subir une suppression logique, une corruption ou une perte avec son support. Une sauvegarde doit avoir un périmètre, une conservation et une procédure de restauration vérifiée. Les tests doivent observer cette reprise, pas seulement la présence d’un nom de volume dans un fichier de configuration.

Ce qui est visible sous un montage

Monter une ressource sur un répertoire déjà rempli peut masquer le contenu présent dans l’image sous ce point. Cela explique certains écarts entre inspection d’image et comportement d’instance. Comparez les deux vues avant de conclure que le build a oublié des fichiers. Le montage n’est pas une fusion universelle de tous les contenus ; ses options et son type doivent être compris selon le contrat utilisé.

Aligner les permissions avec l’utilisateur runtime

Le conteneur utilise un utilisateur et des droits qui doivent permettre les écritures réellement nécessaires, sans élargir tout le stockage. Un volume ne rend pas magiquement tous ses fichiers accessibles à tous les processus. Testez la création, la lecture et la reprise avec l’identité runtime déployée. Une correction qui accorde tous les droits sans limite peut cacher le défaut initial et agrandir le périmètre d’impact.

La lecture seule limite une direction

Un montage en lecture seule peut refuser des modifications par ce point d’accès. Il ne chiffre pas les données et ne décide pas si l’acteur métier peut les consulter. Le service peut aussi disposer d’autres chemins d’écriture selon sa configuration. Décrivez précisément la propriété visée et testez l’opération interdite, puis maintenez les contrôles d’autorisation et de confidentialité nécessaires à la distribution.

Sauvegarder une base dans un état cohérent

Copier arbitrairement les fichiers d’une base active peut produire une copie qui ne respecte pas les conditions de reprise du moteur. Utilisez une méthode de sauvegarde adaptée et conservez ses préconditions, journaux et versions nécessaires. La taille d’une archive ne prouve pas sa cohérence. Restaurez-la dans un laboratoire et vérifiez des invariants métier pour démontrer une capacité utile.

Partager ne sérialise pas les opérations

Plusieurs conteneurs peuvent accéder à des données communes selon le montage choisi. Cette accessibilité ne rend pas atomiques les écritures concurrentes du domaine. Deux travailleurs peuvent lire le même état puis produire des effets incompatibles. Définissez un protocole de coordination adapté au stockage et testez le scénario concurrent. Le mot shared n’est pas un verrou ni une règle de déduplication métier.

Prévoir les suppressions destructives

Certaines commandes de nettoyage peuvent supprimer des volumes et leurs données. La possibilité de recréer un conteneur depuis une image ne signifie pas que ce contenu métier est récupérable. Définissez les ressources éphémères et durables avant une opération, puis vérifiez ses cibles. Une procédure de reprise doit être connue et testée avant de considérer un nettoyage comme réversible.

Valider le résultat restauré

Une restauration techniquement terminée doit encore fournir le résultat utile : rôles, relations, fichiers et parcours applicatifs prévus. Mesurez le délai avec un volume représentatif et conservez les limites de l’exercice. Un succès sur trois fichiers ne justifie pas un objectif de reprise pour toutes les données. La preuve doit relier contenu retrouvé, environnement et contrôles métier observés.

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

services:
  db:
    image: postgres:18
    volumes:
      - lab-data:/var/lib/postgresql
volumes:
  lab-data: {}

La syntaxe de l’exercice nomme lab-data comme volume et le monte à la destination indiquée dans le conteneur. Elle ne désigne pas un chemin absolu du poste comme le ferait un bind mount. Cette configuration de persistance ne crée pas non plus une sauvegarde distante automatique ni une preuve que la base restaurera correctement toutes ses données.

Dans un laboratoire, écrivez une donnée témoin, remplacez le conteneur selon une procédure qui conserve le volume puis vérifiez la lecture. Étudiez séparément une suppression explicite du stockage et une restauration depuis une copie adaptée. Cette séparation rend visibles trois capacités différentes : recréer le processus, conserver son état et récupérer cet état après un incident qui détruit le support courant.