Liste de contrôle des opérations de production pour les volumes nommés Docker avec exemples pratiques

Introduction

Les volumes nommés Docker constituent la méthode recommandée pour persister les données générées et utilisées par les conteneurs Docker. Contrairement aux montages de type bind, les volumes nommés sont gérés par Docker, offrent une sémantique de cycle de vie plus claire, fonctionnent sur différents systèmes de fichiers hôtes et sont plus faciles à sauvegarder ou à migrer. Cependant, lorsque des volumes nommés sont utilisés en production, de petites erreurs de configuration, de surveillance ou de maintenance peuvent entraîner des pertes de données, des problèmes de performances ou des pannes difficiles à diagnostiquer.

Cet article fournit une liste de contrôle opérationnelle pratique pour les volumes nommés Docker en production. Il couvre l'inventaire initial de l'environnement, les choix de configuration sûrs, la vérification et les diagnostics, les modes de défaillance courants et les procédures de récupération, ainsi qu'une liste de contrôle quotidienne reproductible. Chaque section comprend des commandes concrètes, les résultats attendus et des conseils pratiques pour vous aider à éviter les pièges courants. Que vous gériez un seul service avec état ou une pile d'applications multi-nœuds, ce guide vous aidera à exploiter les volumes nommés en toute confiance.

À la fin de cet article, vous serez en mesure de :

• Inventorier les versions de Docker, les pilotes de stockage et les volumes existants.
• Configurer les volumes nommés avec des étiquettes appropriées, des contraintes de taille et des planifications de sauvegarde.
• Vérifier la santé des volumes et leur attachement aux conteneurs.
• Récupérer des volumes corrompus, manquants ou mal configurés.
• Suivre une liste de contrôle opérationnelle reproductible pour la maintenance et la révision.

Inventaire des versions et de l'environnement

Avant d'apporter des modifications aux volumes de production, vous devez comprendre votre environnement actuel. Cela inclut les versions de Docker, les pilotes de stockage, les plugins de volumes, les volumes existants et la manière dont ils sont attachés aux conteneurs. Un inventaire clair réduit les reprises et vous aide à planifier des changements sûrs.

1.1 Vérifier la version de Docker et le pilote de stockage

Le pilote de stockage (overlay2, devicemapper, etc.) affecte la façon dont les volumes sont stockés et dont ils effectuent les sauvegardes.

docker version

Résultat attendu (abrégé) :

Client: Docker Engine - Community
 Version:           24.0.7
 API version:       1.43
 Go version:        go1.20.10
 ...
Server: Docker Engine - Community
 Engine:
  Version:          24.0.7
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.10
  ...

docker info --format '{{.Driver}}'

Résultat attendu :

overlay2

1.2 Lister les volumes existants et leur utilisation

docker volume ls

Résultat attendu :

DRIVER    VOLUME NAME
local     my_app_data
local     postgres_data

Pour voir des informations détaillées sur un volume, y compris son point de montage :

docker volume inspect my_app_data

Résultat attendu :

[
    {
        "CreatedAt": "2024-01-15T10:30:00Z",
        "Driver": "local",
        "Labels": {
            "com.example.project": "myapp"
        },
        "Mountpoint": "/var/lib/docker/volumes/my_app_data/_data",
        "Name": "my_app_data",
        "Options": null,
        "Scope": "local"
    }
]

1.3 Identifier les volumes attachés aux conteneurs

Utilisez docker ps avec un formatage pour lister les conteneurs et leurs volumes.

docker ps --format 'table {{.Names}}\t{{.Mounts}}'

Résultat attendu (peut être large) :

NAMES               MOUNTS
web_server          my_app_data:/var/www/html
postgres_db         postgres_data:/var/lib/postgresql/data

Alternativement, utilisez docker inspect sur un conteneur spécifique :

docker inspect -f '{{ json .Mounts }}' web_server | jq

Résultat attendu :

[
  {
    "Type": "volume",
    "Name": "my_app_data",
    "Source": "/var/lib/docker/volumes/my_app_data/_data",
    "Destination": "/var/www/html",
    "Driver": "local",
    "Mode": "rw",
    "RW": true,
    "Propagation": ""
  }
]

1.4 Vérifier la configuration du démon Docker

Assurez-vous que le démon Docker est configuré de manière appropriée pour votre hôte de production, notamment en ce qui concerne la journalisation et le stockage.

cat /etc/docker/daemon.json

Exemple de résultat attendu :

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "storage-driver": "overlay2"
}

1.5 Tableau d'inventaire de l'environnement

Créez un tableau d'inventaire pour documenter votre environnement. Cela facilite le dépannage et la gestion des changements. Le tableau suivant comprend des valeurs d'exemple ; remplacez-les par vos détails réels.

Remplissez les détails de votre environnement avant de continuer.

Voie de configuration sûre

Lors de la définition et de l'utilisation de volumes nommés, quelques choix de configuration ont un impact important sur la sécurité et la maintenabilité. Cette section couvre la création de volumes, l'étiquetage, les limites de taille et les configurations favorables aux sauvegardes.

2.1 Créer des volumes explicitement avec des étiquettes

Créez toujours des volumes explicitement avec des étiquettes significatives. Les étiquettes aident à l'automatisation, à la comptabilité et au nettoyage.

docker volume create \
  --label com.example.project=myapp \
  --label com.example.environment=production \
  my_app_data

Résultat attendu :

my_app_data

Dans Docker Compose, définissez les volumes au niveau supérieur avec des étiquettes :

volumes:
  my_app_data:
    labels:
      com.example.project: "myapp"
      com.example.environment: "production"

2.2 Utiliser un pilote de volume dédié si nécessaire

Pour le stockage en réseau ou les volumes cloud, utilisez un plugin de volume (par exemple, AWS EBS, NFS). Assurez-vous que le plugin est installé et configuré.

docker plugin ls

Résultat attendu :

ID                  NAME                DESCRIPTION                          ENABLED
acb123def456        rexray/ebs:latest   REX-Ray EBS driver for Amazon EC2   true

2.3 Définir des limites de taille de volume (si pris en charge)

Certains pilotes prennent en charge les options de taille. Pour les volumes locaux, vous pouvez utiliser --opt avec le pilote local sur certaines distributions Linux pour définir une limite de taille via les quotas de projet XFS. Cet exemple nécessite un système de fichiers XFS avec pquota activé :

docker volume create \
  --driver local \
  --opt type=xfs \
  --opt device=/dev/mapper/data \
  --opt o=size=10g \
  my_limited_volume

Remarque : il s'agit d'une option avancée ; testez-la avant de l'utiliser en production.

2.4 Configurer les conteneurs pour utiliser un système de fichiers racine en lecture seule

Pour des raisons de sécurité, exécutez les conteneurs avec un système de fichiers racine en lecture seule, en montant uniquement les volumes nécessaires en écriture.

docker run -d \
  --read-only \
  -v my_app_data:/var/www/html \
  --tmpfs /tmp \
  myapp:latest

Dans Compose :

services:
  web:
    image: myapp:latest
    read_only: true
    tmpfs:
      - /tmp
    volumes:
      - my_app_data:/var/www/html

2.5 Planifier les sauvegardes

Les sauvegardes sont critiques. Utilisez un conteneur de sauvegarde dédié ou un script hôte qui monte temporairement le volume et archive son contenu. L'exemple suivant crée une archive tar horodatée des données du volume à l'aide d'un conteneur Alpine temporaire :

docker run --rm \
  -v my_app_data:/data \
  -v /backup:/backup \
  alpine tar czf /backup/my_app_data_$(date +%Y%m%d).tar.gz -C /data .

Résultat attendu : aucune sortie si réussi, mais le fichier de sauvegarde apparaît dans /backup.

2.6 Tableau d'exemples de configuration

Le tableau ci-dessous résume les pratiques recommandées avec des exemples concrets.

Vérification et diagnostics

Après avoir configuré les volumes, vous devez vérifier qu'ils fonctionnent correctement et mettre en place des diagnostics continus.

3.1 Vérifier la création et l'attachement du volume

Vérifiez que le volume existe et est attaché au conteneur prévu.

docker volume inspect my_app_data

Le résultat attendu doit montrer "Name": "my_app_data" et aucune erreur.

Vérifiez les montages du conteneur :

docker inspect -f '{{ range .Mounts }}{{ .Name }} -> {{ .Destination }} ({{ .Mode }}){{ println }}{{ end }}' web_server

Résultat attendu :

my_app_data -> /var/www/html (rw)

3.2 Tester la lecture/écriture dans le conteneur

Exécutez une commande dans le conteneur et écrivez un fichier de test.

docker exec web_server sh -c 'echo test > /var/www/html/test.txt'

Vérifiez ensuite que le fichier existe sur le point de montage hôte :

cat /var/lib/docker/volumes/my_app_data/_data/test.txt

Résultat attendu :

test

3.3 Surveiller l'utilisation des volumes

Utilisez docker system df pour voir l'utilisation globale du disque, y compris les volumes.

docker system df -v

Résultat attendu (exemple) :

Images space usage:
REPOSITORY   TAG       IMAGE ID       CREATED       SIZE
myapp        latest    abc123def456   2 days ago    1.2GB

Containers space usage:
CONTAINER ID   IMAGE          COMMAND      LOCAL VOLUMES   SIZE
f1e2d3c4b5a6   myapp:latest   "start-app"  1               0B

Local Volumes space usage:
VOLUME NAME     LINKS     SIZE
my_app_data     1         250MB
postgres_data   1         1.1GB

Notez la colonne SIZE pour les volumes. Pour obtenir une utilisation plus détaillée par volume, utilisez du sur le point de montage.

sudo du -sh /var/lib/docker/volumes/my_app_data/_data

Résultat attendu :

250M    /var/lib/docker/volumes/my_app_data/_data

3.4 Vérifier les erreurs de volume dans les journaux Docker

Les journaux du démon Docker peuvent montrer des erreurs liées aux volumes.

journalctl -u docker --since "1 hour ago" | grep -i error

Exemples de résultats attendus :

... error while mounting volume ...
... volume driver error ...

Aucune sortie signifie aucune erreur au cours de la dernière heure.

3.5 Tableau de liste de vérification

Modes de défaillance et récupération

Même avec une configuration soignée, des problèmes surviennent. Cette section décrit les modes de défaillance courants des volumes nommés et comment les récupérer.

4.1 Volume introuvable

Symptôme : Le conteneur ne démarre pas avec l'erreur :

ERROR: for container  Cannot start service: error while mounting volume 'my_app_data': volume my_app_data not found

Cause : Le volume a été supprimé manuellement, ou le conteneur a été déplacé vers un nouvel hôte sans le volume.

Récupération : Recréez le volume à partir de la sauvegarde si possible, ou créez un nouveau volume vide.

docker volume create my_app_data

Si le volume existait sur un autre hôte, copiez ses données manuellement avant de démarrer le conteneur.

4.2 Corruption des données

Symptôme : L'application signale une corruption de base de données ou des fichiers manquants.

Cause : Erreur du système de fichiers hôte, arrêt non gracieux ou bogue du pilote de stockage.

Récupération : Arrêtez le conteneur, démontez le volume, exécutez des vérifications du système de fichiers si possible, restaurez à partir de la sauvegarde.

docker stop web_server
# Inspecter le point de montage du volume
docker volume inspect my_app_data
# Démonter si nécessaire (pas toujours possible pendant que le conteneur tourne)
# Pour les volumes locaux, exécuter fsck sur le système de fichiers hôte
sudo fsck /dev/sda1
# Après correction, redémarrer le conteneur
docker start web_server

Si la corruption persiste, supprimez et recréez le volume à partir de la sauvegarde.

4.3 Volume plein

Symptôme : Les journaux du conteneur montrent « No space left on device », l'application ne peut pas écrire.

Cause : Limite de taille du volume atteinte, ou disque hôte plein.

Récupération : Identifiez les gros fichiers, nettoyez ou étendez le volume.

docker run --rm -v my_app_data:/data alpine du -ah /data | sort -rh | head

Le résultat attendu liste les plus gros fichiers.

Si vous utilisez un pilote de volume avec capacité de redimensionnement, redimensionnez. Pour les volumes locaux, vous devrez peut-être déplacer vers un disque plus grand ou purger les données inutiles.

4.4 Problèmes de permissions

Symptôme : L'application ne peut pas écrire sur le volume, affiche « permission denied ».

Cause : Discordance UID/GID entre l'utilisateur du conteneur et les fichiers du volume.

Récupération : Soit changez la propriété sur le volume, soit exécutez le conteneur avec l'utilisateur approprié. Par exemple, si le conteneur s'exécute en tant qu'UID 1000, définissez la propriété :

docker run --rm -v my_app_data:/data alpine chown -R 1000:1000 /data

Redémarrez ensuite le conteneur.

4.5 Volumes orphelins

Problème : Les volumes inutilisés s'accumulent au fil du temps, consommant de l'espace disque.

Détection : Listez les volumes non référencés par un conteneur.

docker volume ls -qf dangling=true

Résultat attendu : liste des noms de volumes non attachés à un conteneur.

Récupération : Supprimez les volumes orphelins après avoir vérifié qu'ils ne sont pas nécessaires.

docker volume prune

Résultat attendu :

WARNING! This will remove all local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
my_old_volume

4.6 Tableau de liste de récupération

Liste de contrôle des opérations

Une liste de contrôle régulière garantit que les volumes restent sains et récupérables. Attribuez un propriétaire unique pour chaque ensemble de tâches afin d'assurer la responsabilité. Par exemple, Priya Shah, responsable de l'ingénierie, est propriétaire des vérifications quotidiennes et hebdomadaires, tandis que l'ingénieur de garde gère la réponse aux incidents. Révisez la liste de contrôle trimestriellement avec l'équipe d'infrastructure.

Vérifications quotidiennes

• Vérifier que tous les volumes attendus existent : docker volume ls
• Vérifier l'utilisation du disque : docker system df
• Vérifier l'état des conteneurs : docker ps (tous les conteneurs qui devraient tourner tournent)
• Vérifier les journaux du démon Docker pour les erreurs : journalctl -u docker --since "24 hours ago" | grep -i error

Vérifications hebdomadaires

• Examiner les sauvegardes de volumes : confirmer que les fichiers de sauvegarde existent et ne sont pas vides.
• Vérifier les volumes orphelins : docker volume ls -qf dangling=true et les examiner.
• Surveiller les tendances de croissance des volumes à l'aide de du -sh sur les points de montage des volumes.

Vérifications mensuelles

• Tester la procédure de restauration : restaurer une sauvegarde vers un volume de test et vérifier l'intégrité des données. Propriétaire : Administrateur de base de données.
• Examiner les étiquettes et la documentation des volumes : s'assurer qu'elles sont à jour.
• Vérifier les mises à jour de Docker : planifier les mises à niveau du moteur et des plugins de volumes.

Vérifications trimestrielles

• Auditer les contrôles d'accès : s'assurer que seuls les conteneurs nécessaires ont accès aux volumes.
• Examiner la planification de la capacité de stockage : considérer la croissance future.
• Évaluer la politique de rétention des sauvegardes : ajuster si nécessaire.

Exemple de commande de vérification de sauvegarde

ls -lh /backup/

Résultat attendu :

total 250M
-rw-r--r-- 1 root root 250M Jan 15 02:00 my_app_data_20240115.tar.gz

Vérifier l'intégrité de la sauvegarde :

docker run --rm -v /backup:/backup alpine sh -c 'tar tzf /backup/my_app_data_20240115.tar.gz | head'

Résultat attendu : les premiers fichiers listés.

Tableau de liste de contrôle des opérations

Pièges courants et comment les éviter

Au-delà des modes de défaillance spécifiques, plusieurs erreurs opérationnelles surviennent couramment avec les volumes nommés. Comprendre ces pièges à l'avance peut économiser un temps considérable et prévenir les pertes de données.

5.1 Utiliser des volumes anonymes en production

Piège : Exécuter des conteneurs avec -v /chemin/conteneur crée un volume anonyme difficile à suivre et à gérer. Si le conteneur est supprimé, le volume devient orphelin.

Pourquoi cela arrive : Les développeurs utilisent souvent des volumes anonymes par commodité pendant les tests et promeuvent la même commande en production.

Comment éviter : Toujours utiliser des volumes nommés en production. Dans Compose, définissez les volumes au niveau supérieur et référencez-les par nom. Passez en revue toutes les commandes d'exécution de conteneurs et les fichiers Compose pour détecter les volumes anonymes.

Récupération : Identifiez les volumes anonymes avec docker volume ls -f dangling=true et attachez-les à un nouveau conteneur ou supprimez-les s'ils sont inutiles.

5.2 Ne pas étiqueter les volumes

Piège : Sans étiquettes, il est difficile de savoir à quel projet, environnement ou équipe un volume appartient. Automatiser le nettoyage ou la migration devient risqué.

Pourquoi cela arrive : L'étiquetage est une étape supplémentaire facile à ignorer, surtout lors de la création manuelle de volumes.

Comment éviter : Imposer l'étiquetage via des contrôles de pipeline CI/CD ou utiliser un script d'encapsulation pour la création de volumes.

5.3 Ignorer la vérification des sauvegardes

Piège : Les sauvegardes peuvent être créées mais jamais testées, ce qui donne un faux sentiment de sécurité.

Pourquoi cela arrive : Tester les restaurations prend du temps et est souvent reporté.

Comment éviter : Planifiez des tests de restauration mensuels vers un environnement séparé. Utilisez la commande de vérification de sauvegarde montrée précédemment pour au moins lister le contenu des archives.

5.4 Exécuter les conteneurs en tant que root

Piège : De nombreuses images Docker s'exécutent par défaut en tant que root. Si le conteneur écrit dans un volume, les fichiers appartiennent à root, ce qui cause des problèmes de permissions pour d'autres conteneurs ou processus hôtes.

Pourquoi cela arrive : Configuration d'image par défaut et manque de sensibilisation.

Comment éviter : Spécifiez un utilisateur non-root dans votre Dockerfile ou définissez user: dans Compose. Assurez-vous que le point de montage du volume a la bonne propriété.

5.5 Ne pas surveiller la capacité des volumes

Piège : Les volumes se remplissent de manière inattendue, provoquant des erreurs d'application.

Pourquoi cela arrive : Les tendances de croissance ne sont pas suivies et les alertes ne sont pas configurées.

Comment éviter : Utilisez des outils de surveillance pour alerter sur les seuils d'utilisation des volumes (par exemple, 80 %). Intégrez docker system df ou du dans vos scripts de surveillance.

Conclusion

Les volumes nommés Docker sont un moyen fiable de persister les données, mais ils nécessitent une gestion active. Cet article a fourni une liste de contrôle opérationnelle complète couvrant l'inventaire de l'environnement, la configuration sûre, la vérification, la récupération après défaillance et la maintenance régulière. En suivant les commandes et procédures décrites, vous pouvez minimiser le risque de perte de données et assurer le bon fonctionnement de vos conteneurs avec état.

Pour vos prochaines étapes, commencez par une mise en œuvre pilote : choisissez un volume, appliquez les étapes d'inventaire et de configuration, puis mettez en place la surveillance et la vérification des sauvegardes. Comme recommandé, gardez le pilote étroit, mesurable et facile à inspecter localement avant de l'étendre à d'autres volumes. Une fois que vous avez validé l'approche, intégrez les vérifications quotidiennes et hebdomadaires dans votre routine et planifiez des tests de restauration mensuels.

Attribuez un propriétaire unique, comme un ingénieur d'infrastructure senior, pour être responsable des opérations de volumes, et révisez la liste de contrôle trimestriellement pour l'adapter aux changements de votre environnement.

N'oubliez pas qu'une liste de contrôle opérationnelle claire réduit les reprises et aide votre équipe à maintenir des services de données cohérents et fiables. Utilisez ce guide comme un document vivant et mettez-le à jour à mesure que votre environnement évolue.