Planification de la capacité des volumes nommés Docker : guide pratique de mise en œuvre

Introduction

Les volumes nommés Docker sont la méthode recommandée pour persister les données générées et utilisées par les conteneurs. Contrairement aux montages de liaison, les volumes nommés sont gérés par Docker, peuvent être partagés entre conteneurs et fonctionnent avec différents pilotes de stockage. Cependant, comme les volumes nommés existent sur le système de fichiers de l'hôte, ils consomment de l'espace disque. Sans une planification minutieuse, un volume en croissance peut remplir le disque hôte, provoquant des erreurs applicatives, une corruption de base de données ou des interruptions de service complètes.

La planification de la capacité des volumes nommés consiste à estimer l'espace nécessaire pour un volume, à surveiller son utilisation réelle et à définir des limites et des alertes appropriées avant que les problèmes ne surviennent. Elle transforme la gestion du stockage d'une lutte réactive en une tâche opérationnelle prévisible. Ce guide propose une approche pratique pour planifier la capacité des volumes nommés. Vous apprendrez à inspecter les volumes, à prévoir leur croissance, à appliquer des limites et à récupérer après des scénarios de volume plein.

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

• Estimer la taille et le taux de croissance d'un volume nommé.
• Configurer les volumes avec des options adaptées à votre environnement.
• Surveiller l'utilisation du disque et définir des alertes.
• Augmenter la capacité en toute sécurité si nécessaire.
• Récupérer après un épuisement du volume.

Inventaire de la version et de l'environnement

Avant de pouvoir planifier la capacité, vous devez avoir une vision claire de votre environnement Docker. La version de Docker, le pilote de stockage, le système de fichiers de l'hôte et l'emplacement du répertoire de données Docker influencent le comportement des volumes nommés.

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

Exécutez la commande suivante pour voir la version de Docker et le pilote de stockage actuel :

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

Exemple de sortie attendue :

24.0.7 overlay2

Le pilote de stockage affecte la manière dont les volumes sont implémentés. Avec overlay2, les volumes nommés sont stockés sous forme de répertoires sous /var/lib/docker/volumes/ par défaut, mais ce chemin peut être modifié.

Localiser le répertoire racine de Docker

Pour trouver où Docker stocke ses données (y compris les volumes), exécutez :

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

Sortie typique :

/var/lib/docker

Si vous avez déplacé le répertoire de données Docker vers un autre disque (par exemple, un disque de données dédié), cela affichera le chemin personnalisé. Tous les volumes nommés résident sous <DockerRootDir>/volumes/<nom-volume>/_data.

Identifier les volumes existants et leurs points de montage

Listez tous les volumes nommés :

docker volume ls

Exemple de sortie :

DRIVER    VOLUME NAME
local     myapp_data
local     postgres_data

Inspectez un volume spécifique pour voir son point de montage et ses options de pilote :

docker volume inspect myapp_data

Exemple de sortie :

[
  {
    "CreatedAt": "2025-01-15T10:30:00Z",
    "Driver": "local",
    "Labels": {},
    "Mountpoint": "/var/lib/docker/volumes/myapp_data/_data",
    "Name": "myapp_data",
    "Options": {},
    "Scope": "local"
  }
]

Le point de montage est l'endroit où les données résident réellement sur l'hôte. Vous pouvez inspecter ce répertoire directement, mais veillez à ne pas modifier les fichiers pendant que le conteneur est en cours d'exécution, sauf si vous comprenez les exigences de cohérence de l'application.

Système de fichiers de l'hôte et espace disque

Vérifiez l'espace disque disponible sur le système de fichiers racine de Docker :

df -h /var/lib/docker

Exemple de sortie :

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       100G   45G   55G  45% /var/lib/docker

Si la racine Docker se trouve sur un petit disque système, envisagez de la déplacer vers une partition plus grande ou un disque dédié. La planification de la capacité doit tenir compte de l'ensemble du disque hôte, et pas seulement des volumes individuels, car les volumes partagent le même système de fichiers sous-jacent, sauf si vous utilisez des pilotes de volume mappés vers un stockage externe.

Prérequis pour une planification efficace

• Docker version 20.10+ : Nécessaire pour les options de montage de volume comme size avec le pilote de volume local (nécessite xfs ou ext4 avec des quotas de projet).
• Support des quotas par le système de fichiers hôte : Pour les limites de taille par volume, vous avez besoin d'un système de fichiers prenant en charge les quotas de projet (XFS ou ext4). C'est un prérequis essentiel pour l'application des limites.
• Système de surveillance : Une méthode pour collecter et alerter sur les métriques d'utilisation du disque, comme Prometheus, Zabbix ou un simple script cron.
• Accès à l'hôte Docker : Vous avez besoin d'un accès SSH ou similaire pour exécuter des commandes et inspecter les répertoires.

Chemin de configuration sûr

La planification de la capacité implique à la fois l'estimation et l'application des limites. Vous pouvez commencer par des estimations, mais à mesure que les volumes croissent, vous avez besoin de mécanismes pour limiter et surveiller l'utilisation.

Étape 1 : Estimer la taille initiale du volume

Estimez la taille initiale en fonction des données attendues de l'application. Pour les bases de données, cela peut être la taille d'un jeu de données typique ou le nombre de lignes attendues multiplié par la taille moyenne d'une ligne. Pour le stockage de fichiers, cela pourrait être le nombre de fichiers multiplié par la taille moyenne d'un fichier. Ajoutez toujours une marge de sécurité (par exemple, 30 %) pour tenir compte des index, des fichiers temporaires et de la croissance imprévue.

Par exemple, supposons que vous exécutiez PostgreSQL pour une petite application. Vous estimez que la base de données démarrera avec 2 Go de données. Ajoutez une marge de 30 %, ce qui donne 2,6 Go. Arrondissez à 3 Go pour le volume.

Cependant, avec le pilote de volume local, vous ne pouvez pas définir une taille initiale ; le volume croîtra jusqu'à atteindre toute limite configurée. Au lieu de cela, vous pouvez pré-créer une image de système de fichiers et la monter, mais cela dépasse le cadre des volumes nommés. Concentrez-vous plutôt sur la définition d'une limite.

Étape 2 : Définir une limite de taille de volume à l'aide des quotas de projet

Le pilote de volume local de Docker prend en charge l'option size lorsque le système de fichiers sous-jacent est XFS ou ext4 avec les quotas de projet activés. Cette option impose une taille maximale pour le volume.

Pour créer un volume nommé avec une limite de taille, vous devez activer les quotas de projet sur le système de fichiers contenant /var/lib/docker/volumes. Voici comment procéder :

1. Assurez-vous que le système de fichiers est monté avec l'option pquota (pour XFS) ou prjquota (pour ext4). Par exemple, pour remonter /var/lib/docker avec les quotas de projet (si sur XFS) :

   mount -o remount,pquota /var/lib/docker

1. Créez le volume avec l'option size en utilisant le pilote local et type=none avec un montage de liaison vers le chemin du volume. C'est une solution de contournement car le pilote local ne prend pas directement en charge les limites de taille sans montage de liaison.

   docker volume create \
     --driver local \
     --opt type=none \
     --opt o=bind \
     --opt device=/var/lib/docker/volumes/myapp_data/_data \
     --opt size=10g \
     myapp_data

Cette commande est compliquée et n'est pas recommandée en production. Une approche plus propre est d'utiliser un plugin de volume comme local-persist ou rexray, mais la plus simple est de gérer la capacité au niveau du système de fichiers ou d'utiliser un disque/partition dédié pour chaque volume si une isolation stricte est nécessaire.

Alternativement, vous pouvez créer un volume sur un système de fichiers monté qui prend en charge les quotas, puis utiliser l'option size de Docker. Mais pour de nombreux environnements, l'approche pratique consiste à surveiller et à faire croître les volumes plutôt que de les limiter strictement, car atteindre une limite stricte peut provoquer des erreurs applicatives.

Étape 3 : Choisir une stratégie de surveillance et d'alerte

Étant donné que les limites par volume sont délicates, appuyez-vous sur la surveillance. Configurez des alertes d'utilisation du disque au niveau de l'hôte et au niveau de chaque volume. Vous pouvez utiliser la commande suivante pour vérifier la taille du répertoire de données d'un volume :

du -sh /var/lib/docker/volumes/myapp_data/_data

Exemple de sortie :

1.2G    /var/lib/docker/volumes/myapp_data/_data

Planifiez cette commande (ou son équivalent dans votre agent de surveillance) pour qu'elle s'exécute périodiquement, et alertez lorsque l'utilisation dépasse un seuil (par exemple, 80 % du disque hôte ou une limite maximale prédéfinie pour le volume).

Étape 4 : Utiliser Docker Compose avec la configuration de volume

Dans Docker Compose, définissez des volumes nommés avec des options de pilote si nécessaire. Exemple de docker-compose.yml :

version: '3.8'
services:
  db:
    image: postgres:16
    volumes:
      - db_data:/var/lib/postgresql/data
volumes:
  db_data:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /mnt/data/db_data

Cet exemple monte le volume depuis un répertoire spécifique sur un disque de données dédié (/mnt/data), isolant le stockage de la base de données du disque du système d'exploitation. C'est un modèle de configuration sûr : séparez les disques de données par service.

Étape 5 : Planifier la croissance et la mise à l'échelle

Même avec des quotas, vous avez besoin d'un processus pour augmenter la taille du volume. Pour les volumes locaux, cela signifie souvent :

• Si le volume est sur une partition ou un volume logique séparé, vous pouvez étendre cette partition (par exemple, en utilisant lvextend et resize2fs).
• Si le volume est sur un système de fichiers partagé, vous devrez peut-être migrer les données vers un volume plus grand en utilisant une sauvegarde et une restauration.
• Envisagez d'utiliser un pilote de volume qui prend en charge le redimensionnement dynamique, comme les volumes des fournisseurs de cloud (par exemple, AWS EBS avec rexray/ebs).

Vérification et diagnostics

Maintenant que vous avez configuré les volumes et mis en place la surveillance, vérifiez que votre planification de la capacité est efficace.

Vérifier le montage et la taille du volume

Après avoir créé un volume, inspectez-le :

docker volume inspect myapp_data

Vérifiez que le point de montage existe et que les options sont conformes aux attentes.

Vérifier l'utilisation réelle du volume

Utilisez du sur le point de montage :

du -sh /var/lib/docker/volumes/myapp_data/_data

Tester le comportement de l'application avec un espace limité

Pour simuler un volume presque plein, vous pouvez créer un volume de test avec une petite limite de taille (si les quotas fonctionnent) ou simplement remplir le volume avec des données factices pour voir comment l'application répond. Par exemple, dans un conteneur de test :

docker run --mount type=volume,src=test_vol,dst=/data alpine dd if=/dev/zero of=/data/testfile bs=1M count=100

Vérifiez ensuite la taille du volume et tentez d'écrire davantage de données pour voir si l'application gère correctement les erreurs de type « disque plein ».

Surveiller l'utilisation du disque hôte au fil du temps

Configurez une tâche cron qui enregistre l'utilisation du disque dans un journal :

0 * * * * df -h /var/lib/docker >> /var/log/docker_disk.log

Consultez régulièrement le journal pour identifier les tendances de croissance.

Vérifier l'application des quotas (si utilisés)

Si vous avez réussi à configurer les quotas de projet, testez que le volume cesse de croître à la limite :

docker run --rm -v limited_vol:/data alpine sh -c 'dd if=/dev/zero of=/data/bigfile bs=1M count=10000'

Vous devriez voir une erreur « no space left on device » une fois la limite atteinte.

Pièges courants et comment les éviter

Même les opérateurs expérimentés commettent des erreurs avec la capacité des volumes nommés. Voici les pièges les plus fréquents, pourquoi ils surviennent et comment les prévenir ou s'en remettre.

Piège 1 : Ignorer l'utilisation du disque hôte

Pourquoi cela arrive : Les équipes se concentrent sur la taille des volumes individuels mais oublient que tous les volumes partagent le même système de fichiers hôte. Un seul volume incontrôlé peut remplir tout le disque.

Comment l'éviter : Surveillez à la fois l'utilisation du disque hôte et celle de chaque volume. Définissez des alertes pour une utilisation du disque hôte supérieure à 80 % et enquêtez sur toute croissance rapide.

Récupération : Si le disque hôte est plein, libérez de l'espace en supprimant les images inutilisées (docker image prune -a), en arrêtant les conteneurs non critiques ou en déplaçant les volumes vers un autre disque.

Piège 2 : Supposer que l'emplacement par défaut du volume est sûr

Pourquoi cela arrive : Le répertoire par défaut /var/lib/docker se trouve souvent sur le système de fichiers racine, qui peut être petit ou partagé avec le système d'exploitation. Un volume volumineux peut remplir le système de fichiers racine et faire tomber tout l'hôte.

Comment l'éviter : Déplacez le répertoire de données Docker vers un disque ou une partition dédié, ou utilisez des pilotes de volume qui stockent les données à l'extérieur. Au minimum, surveillez de près le système de fichiers racine.

Récupération : Si le système de fichiers racine est plein, démarrez en mode de secours, déplacez /var/lib/docker vers un disque plus grand et mettez à jour la configuration de Docker pour pointer vers le nouvel emplacement.

Piège 3 : Mal configurer les quotas de projet

Pourquoi cela arrive : L'activation des quotas de projet nécessite des options de montage spécifiques et un support du système de fichiers. Des erreurs ici peuvent empêcher le montage des volumes ou l'application des quotas.

Comment l'éviter : Testez d'abord la configuration des quotas dans un environnement de préproduction. Vérifiez les options de montage avec mount | grep /var/lib/docker et assurez-vous que le type de système de fichiers est XFS ou ext4 avec support des quotas.

Récupération : Si les quotas sont mal configurés, remontez le système de fichiers avec les bonnes options, recréez le volume avec les options appropriées et restaurez les données à partir d'une sauvegarde.

Piège 4 : Définir des limites trop strictes

Pourquoi cela arrive : Les équipes définissent des limites de taille de volume basées sur des estimations initiales sans tenir compte de la croissance. Atteindre une limite stricte provoque des erreurs applicatives et des échecs d'écriture de données.

Comment l'éviter : Définissez des limites avec une marge de sécurité généreuse (par exemple, 50 % au-dessus du maximum attendu) et mettez en place une surveillance pour alerter avant que la limite ne soit atteinte. Envisagez d'utiliser des limites souples ou aucune limite avec une forte surveillance pour les données critiques.

Récupération : Si un volume atteint sa limite, augmentez la limite si possible ou migrez vers un volume plus grand. Nettoyez tout fichier inutile pour libérer temporairement de l'espace.

Piège 5 : Négliger les sauvegardes

Pourquoi cela arrive : Avec l'accent mis sur la planification de la capacité, les sauvegardes sont souvent oubliées. Un volume plein peut entraîner une corruption ou une perte de données s'il n'est pas géré correctement.

Comment l'éviter : Planifiez des sauvegardes régulières des volumes nommés à l'aide d'outils comme docker run --rm -v volume:/data -v /backup:/backup alpine tar czf /backup/volume.tar.gz -C /data .. Testez régulièrement les procédures de restauration.

Récupération : Si des données sont perdues, restaurez à partir de la dernière sauvegarde. S'il n'y a pas de sauvegarde, arrêtez les écritures sur le volume et consultez un spécialiste de la récupération de données.

Modes de défaillance et récupération

Même avec une planification minutieuse, les volumes peuvent se remplir. Voici les modes de défaillance courants et comment récupérer.

Volume plein : erreurs applicatives

Symptôme : L'application journalise des erreurs telles que « No space left on device » ou « disk full ». La base de données peut planter ou refuser les écritures.

Diagnostic : Vérifiez l'utilisation du disque hôte :

df -h /var/lib/docker

Vérifiez quel volume consomme de l'espace :

du -sh /var/lib/docker/volumes/*/_data | sort -h

Récupération :

• Identifiez le volume volumineux.
• Déterminez si la croissance est légitime (données utilisateur) ou due à des journaux/fichiers temporaires incontrôlés.
• Si les journaux sont en cause, nettoyez-les (par exemple, docker system prune ou rotation des journaux de l'application).
• Si elle est légitime, étendez la capacité du volume si possible ou migrez vers un disque plus grand.

Disque hôte plein : Docker ne répond plus

Symptôme : Les commandes Docker se bloquent ou échouent car le démon ne peut pas écrire dans ses propres métadonnées.

Diagnostic : df -h / affiche 100 % d'utilisation.

Récupération :

• Connectez-vous à l'hôte via SSH (si possible).
• Supprimez les fichiers inutiles pour libérer de l'espace (par exemple, les anciennes images Docker : docker image prune -a).
• Redémarrez Docker si nécessaire : systemctl restart docker.
• Déplacez les volumes vers un autre disque si possible.

Corruption de volume ou perte de données

Symptôme : L'application signale des données corrompues ou des fichiers manquants.

Diagnostic : Vérifiez l'intégrité du système de fichiers (fsck sur le volume démonté) et les journaux de l'application.

Récupération : Restaurez à partir d'une sauvegarde. Cela souligne la nécessité de sauvegardes régulières des volumes nommés. Utilisez docker run --rm -v myapp_data:/data -v /backup:/backup alpine tar czf /backup/myapp_data.tar.gz -C /data . pour créer des sauvegardes.

Retour en arrière après un mauvais changement de configuration

Si vous avez modifié les options de montage d'un volume ou déplacé des données et que l'application échoue, revenez à la configuration précédente. Par exemple, si vous avez modifié docker-compose.yml avec un nouveau chemin de périphérique, restaurez l'ancien fichier et recréez le service. Conservez des sauvegardes des fichiers de configuration.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour assurer une gestion continue de la capacité des volumes nommés Docker. Attribuez un responsable unique pour chaque tâche récurrente et définissez les fréquences de révision.

Hebdomadaire

• [ ] Vérifier l'utilisation du disque sur le système de fichiers racine de Docker : df -h /var/lib/docker. Responsable : ingénieur DevOps (par exemple, Alex Johnson). Alerter si l'utilisation > 80 %.
• [ ] Vérifier la taille de chaque volume : du -sh /var/lib/docker/volumes/*/_data. Responsable : ingénieur DevOps. Journaliser les résultats pour l'analyse des tendances.
• [ ] Examiner les journaux d'alerte pour tout avertissement d'espace disque. Responsable : ingénieur de garde. Enquêter sur tout avertissement.

Mensuel

• [ ] Analyser les tendances de croissance à partir des données de surveillance. Responsable : responsable DevOps (par exemple, Maria Garcia). Calculer le taux de croissance et projeter les besoins futurs.
• [ ] Prévoir quand les volumes atteindront leur capacité (basé sur le taux de croissance linéaire). Responsable : responsable DevOps. Utiliser la formule : capacité restante / croissance mensuelle moyenne.
• [ ] Tester la procédure de sauvegarde et de restauration pour les volumes critiques. Responsable : administrateur de base de données (par exemple, John Kim). Effectuer une restauration de test dans un environnement de préproduction.
• [ ] Vérifier que les limites de volume (si utilisées) sont toujours appropriées. Responsable : ingénieur DevOps. Ajuster les limites en fonction des modèles d'utilisation réels.

Trimestriel

• [ ] Évaluer si les volumes doivent être déplacés vers un stockage plus grand ou plus rapide. Responsable : gestionnaire d'infrastructure (par exemple, Sarah Lee). Tenir compte des métriques de performance et des coûts.
• [ ] Examiner les mises à jour de la version de Docker et du pilote de stockage pour les améliorations de volume. Responsable : responsable DevOps. Planifier les mises à niveau si elles sont bénéfiques.
• [ ] Auditer quels conteneurs ont un accès en écriture à quels volumes. Responsable : ingénieur en sécurité (par exemple, David Chen). Assurer le moindre privilège.

À la demande

• [ ] Lorsqu'un nouveau service est déployé, estimer ses besoins en volume et configurer la surveillance. Responsable : propriétaire du service. Documenter l'estimation de taille et les hypothèses de croissance.
• [ ] Lorsqu'un volume atteint 70 % de son maximum prévu, déclencher une expansion ou un nettoyage. Responsable : ingénieur DevOps. Suivre la procédure pour augmenter la capacité ou nettoyer les données.
• [ ] En cas d'incident de volume plein, suivre les étapes de récupération ci-dessus. Responsable : ingénieur de garde. Journaliser l'incident et effectuer un post-mortem.

Conclusion

Les volumes nommés Docker simplifient la persistance des données, mais ils nécessitent une planification proactive de la capacité. En comprenant votre environnement, en estimant la croissance, en définissant des limites appropriées et en surveillant l'utilisation, vous pouvez prévenir les pannes liées au stockage. N'oubliez pas que les volumes nommés vivent sur le système de fichiers de l'hôte, donc garder un œil sur l'ensemble du disque est tout aussi important que les vérifications par volume.

Commencez par un pilote étroit : créez un volume nommé pour un service à faible risque, configurez la surveillance et observez son comportement pendant quelques semaines. Utilisez les commandes et les listes de contrôle de ce guide pour gagner en confiance. Élargissez ensuite votre approche à tous les volumes de production, en veillant à ce que chacun ait un propriétaire défini, une projection de croissance et un plan de sauvegarde.

La planification de la capacité n'est pas une tâche ponctuelle ; c'est une discipline continue. Intégrez ces vérifications dans vos opérations régulières et ajustez-les à mesure que vos applications évoluent.