Planification des capacités Docker : exemples pratiques pour dimensionner correctement les conteneurs

Un guide pratique pour planifier les capacités des hôtes et conteneurs Docker, estimer les ressources, définir des limites, reconnaître les signaux de mise à l’échelle et appliquer des marges de sécurité avec des exemples concrets.

Introduction

La planification des capacités Docker est le processus d’estimation et d’allocation des ressources de calcul, mémoire, stockage et réseau pour les charges de travail conteneurisées. Sans planification délibérée, les équipes rencontrent souvent des pannes inattendues, des dépenses cloud gaspillées ou des objectifs de performance manqués. Ce guide fournit une approche pratique, étape par étape, pour la planification des capacités des hôtes et conteneurs Docker. Vous apprendrez à inventorier votre environnement, définir des limites de ressources, vérifier les configurations, diagnostiquer les problèmes et établir une liste de contrôle opérationnelle. Les exemples utilisent des commandes Docker CLI et des fichiers Compose, et tous les chiffres sont illustratifs, à adapter à votre charge de travail.

Inventaire de la version et de l’environnement

Avant de modifier toute limite, enregistrez la version Docker actuelle, les spécifications de l’hôte et les charges de travail en cours d’exécution. Cette base de référence vous aide à comprendre ce que vous avez, à identifier les conteneurs sans limites et à suivre les changements au fil du temps.

Vérifier les versions de Docker et du système d’exploitation

Exécutez :

docker version --format '{{.Server.Version}}'

Exemple de sortie :

20.10.12

Enregistrez le noyau hôte et le système d’exploitation :

uname -r && cat /etc/os-release | head -n 2

Exemple de sortie :

5.4.0-109-generic
NAME="Ubuntu"
VERSION="20.04.4 LTS (Focal Fossa)"

Inspecter les ressources de l’hôte

Utilisez free -h pour la mémoire, nproc pour les CPU et df -h pour le stockage.

Exemple d’hôte : 4 vCPU, 16 Go de RAM, 100 Go de disque.

free -h
nproc
df -h /

Sortie typique :

              total        used        free      shared  buff/cache   available
Mem:           15Gi       3.2Gi        10Gi       256Mi       1.8Gi        11Gi
Swap:         2.0Gi          0B       2.0Gi
4
/dev/sda1        98G   32G   61G  35% /

Lister les conteneurs en cours d’exécution et leur utilisation des ressources

docker stats --no-stream

Exemple de sortie (tronquée) :

CONTAINER ID   NAME   CPU %   MEM USAGE / LIMIT     MEM %   NET I/O          BLOCK I/O   PIDS
abc123         web    0.50%   256MiB / 15.6GiB      1.60%   1.2MB / 300kB    0B / 0B     10
def456         db     2.10%   1.1GiB / 15.6GiB      7.03%   500kB / 200kB    10MB / 2MB  25

Notez quels conteneurs n’ont pas de limite mémoire (indiquée comme le total de l’hôte) et lesquels ont des limites explicites. Dans l’exemple ci-dessus, les deux conteneurs affichent le total de l’hôte (15,6 Gio) comme limite, ce qui signifie qu’aucune limite n’est définie. Cette base de référence aide à identifier où concentrer la planification.

Prérequis pour la planification des capacités

• Docker Engine 20.10 ou version ultérieure (pour la prise en charge de cgroup v2).
• Accès au démon Docker avec les autorisations appropriées.
• Un environnement de test ou de préproduction pour valider les changements avant la production.
• Outils de surveillance (par exemple, Prometheus, cAdvisor ou Docker stats) pour collecter les métriques.

Estimation des besoins en ressources

Avant de définir des limites, estimez ce dont chaque conteneur a réellement besoin. Utilisez une combinaison d’observation, de tests de charge et de connaissance de l’application.

Observer l’utilisation existante

Si le conteneur est déjà en cours d’exécution, laissez-le fonctionner sous charge normale pendant au moins 24 à 48 heures et capturez l’utilisation maximale. Utilisez docker stats périodiquement ou un système de surveillance.

Exemple : pour un conteneur web, vous pourriez voir une utilisation moyenne du CPU de 0,3 cœur, un pic de 1,2 cœur ; mémoire moyenne de 300 Mo, pic de 800 Mo. Utilisez le pic comme point de départ pour les limites.

Tests de charge

Si le conteneur est nouveau ou que vous anticipez un pic de trafic, simulez la charge avec des outils comme ab, wrk ou hey. Exécutez le conteneur avec des limites généreuses initialement, puis mesurez.

docker run -d --name myapp-test --cpus=4 --memory=4g myimage:latest
# Générer la charge depuis l’hôte ou un autre conteneur
ab -n 10000 -c 100 http://localhost:8080/

Pendant que le test s’exécute, surveillez docker stats myapp-test et notez les pics de CPU et de mémoire.

Connaissance de l’application

Consultez les développeurs ou la documentation pour les profils de ressources attendus. Une application Java avec un tas de 2 Go aura besoin de plus de mémoire que la taille du tas en raison de la surcharge. Un transcodeur vidéo lié au CPU peut nécessiter plusieurs cœurs.

Ajouter une marge de sécurité

Les limites ne doivent pas être définies au pic exact. Ajoutez une marge de 20 à 30 % pour la marge de manœuvre et les pics inattendus. Pour l’exemple web ci-dessus, vous pourriez définir une limite CPU de 1,5 cœur et une limite mémoire de 1 Go.

Chemin de configuration sûr

Définissez des limites de ressources sur les conteneurs pour empêcher une charge de travail unique d’affamer les autres. Les principaux contrôles sont les limites CPU et mémoire. Les limites de stockage et de réseau sont moins couramment gérées par conteneur, mais vous devez les planifier au niveau de l’hôte.

Limites CPU

Docker utilise les partages CPU pour le poids relatif et le quota CPU pour les limites strictes. Pour simplifier, commencez par le quota CPU en utilisant --cpus.

Exemple : limiter un conteneur à 1,5 CPU

docker run -d --name myapp --cpus="1.5" myimage:latest

Pour vérifier :

docker inspect myapp --format '{{.HostConfig.NanoCpus}}'

Sortie attendue : 1500000000 (nano CPU).

Si le conteneur tente d’utiliser plus de 1,5 cœur, il sera limité.

Limites mémoire

Les limites mémoire sont critiques car leur dépassement peut amener le tueur OOM à terminer les processus. Utilisez --memory et éventuellement --memory-swap.

Exemple : limiter la mémoire à 512 Mo et interdire le swap

docker run -d --name myapp --memory="512m" --memory-swap="512m" myimage:latest

En définissant --memory-swap égal à --memory, le conteneur ne peut pas utiliser le swap.

Pour vérifier depuis l’intérieur du conteneur, vérifiez les limites cgroup :

docker exec myapp cat /sys/fs/cgroup/memory.max

Sortie attendue (en octets) : 536870912.

Configuration Docker Compose

Pour les applications multi-conteneurs, définissez les limites dans docker-compose.yml.

services:
  web:
    image: nginx:1.23
    deploy:
      resources:
        limits:
          cpus: '0.50'
          memory: 256M
        reservations:
          cpus: '0.25'
          memory: 128M

Remarque : deploy.resources s’applique au mode Swarm. Pour Compose non-Swarm, utilisez les clés mem_limit et cpus (format version 2) ou le bloc resources dans la version 3 avec docker-compose v1.28+.

Pour la dernière spécification Compose, utilisez le bloc resources sous services (pas deploy) si vous n’utilisez pas Swarm :

services:
  web:
    image: nginx:1.23
    resources:
      limits:
        cpus: '0.50'
        memory: 256M
      reservations:
        cpus: '0.25'
        memory: 128M

Planification du stockage et du réseau

• Stockage : Surveillez l’utilisation du disque hôte et les couches inscriptibles des conteneurs. Utilisez docker system df pour voir l’espace utilisé par les images, les conteneurs et les volumes.

docker system df

Exemple de sortie :

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          12        3         4.2GB     2.1GB (50%)
Containers      8         5         1.5GB     100MB (6%)
Local Volumes   4         2         3.8GB     0B (0%)
Build Cache     0         0         0B        0B

• Réseau : Si vous utilisez des réseaux pont définis par l’utilisateur, assurez une plage IP adéquate et évitez l’épuisement des ports.

Évitez de définir des quotas de stockage par conteneur sauf si vous utilisez des pilotes de stockage spécifiques (par exemple, overlay2 avec des quotas de projet). Pour la plupart des équipes, la surveillance au niveau de l’hôte suffit.

Vérification et diagnostics

Après avoir appliqué les limites, vérifiez leur efficacité et surveillez les signes de pression sur les ressources.

Vérifier les limites effectives

Utilisez docker inspect pour confirmer que les limites sont définies :

docker inspect --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}' myapp

Exemple de sortie : 536870912 1500000000.

Surveiller l’utilisation en cours d’exécution

docker stats myapp --no-stream

Observez la colonne MEM USAGE / LIMIT ; si l’utilisation est proche de la limite, le conteneur peut être sous stress.

Simuler la charge pour valider les limites

Pour le CPU, exécutez un outil de stress à l’intérieur du conteneur (si disponible) et observez la limitation :

docker exec myapp sh -c "apt-get update && apt-get install -y stress && stress --cpu 4"

Dans un autre terminal, docker stats affichera un pourcentage CPU plafonné à la limite (par exemple, 150 % pour 1,5 CPU). Pour la mémoire, vous pouvez allouer de la mémoire dans un conteneur de test et confirmer qu’il est tué à la limite.

Diagnostics au niveau de l’hôte

• free -h pour voir la pression mémoire de l’hôte.
• vmstat 1 pour observer la file d’attente CPU et le swap.
• iostat -x 1 pour la saturation des E/S disque.
• docker events pour détecter les OOM kills ou les redémarrages.

Résultats attendus et seuils

Définissez des seuils acceptables. Par exemple :

• Limitation CPU : si nr_throttled dans les statistiques CPU cgroup augmente de manière significative, le conteneur est limité.
• Mémoire : si l’utilisation de la mémoire du conteneur dépasse constamment 80 % de la limite, envisagez d’augmenter la limite ou d’optimiser l’application.
• Hôte : maintenez au moins 20 % de mémoire libre et de marge CPU pour le démon Docker et les processus système.

Modes de défaillance et récupération

Défaillances courantes liées à la capacité et comment récupérer.

Tués par manque de mémoire (OOM)

Lorsqu’un conteneur dépasse sa limite mémoire, le tueur OOM du noyau termine un processus à l’intérieur du conteneur. Le conteneur peut redémarrer si une politique de redémarrage est définie.

Détection : docker inspect myapp --format '{{.State.OOMKilled}}' renvoie true. Consultez également les journaux du noyau (dmesg | grep -i oom).

Récupération : Augmentez la limite mémoire si la charge de travail en a légitimement besoin de plus, ou optimisez l’application. Revenez en arrière en restaurant la limite précédente et en redémarrant le conteneur.

Famine CPU

Si un conteneur est limité en CPU, il peut subir une latence élevée. Vérifiez docker stats pour un pourcentage CPU élevé égal à la limite, et inspectez le cgroup cpu.stat pour nr_throttled :

docker exec myapp cat /sys/fs/cgroup/cpu.stat

Si la limitation est sévère, augmentez le quota CPU ou déplacez la charge de travail vers un hôte plus grand.

Disque plein

Les conteneurs écrivant des journaux ou des données peuvent remplir le disque hôte. Cela peut causer des problèmes avec le démon Docker.

Détection : df -h montre une utilisation élevée ; docker system df montre de gros volumes ou journaux de conteneurs.

Récupération : Nettoyez les images/conteneurs inutilisés (docker system prune), faites tourner les journaux ou ajoutez du stockage. Pour éviter la récidive, configurez la rotation des journaux dans daemon.json ou par conteneur.

Plan de retour en arrière

Documentez toujours les paramètres de ressources précédents. Utilisez des fichiers de configuration (Compose, scripts) sous contrôle de version. Pour revenir en arrière, annulez la configuration et redémarrez le conteneur ou le service. Exemple :

docker compose down && git checkout previous-compose.yml && docker compose up -d

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour la gestion continue des capacités.

Pratiques opérationnelles supplémentaires

• Définissez des alertes pour une utilisation des ressources hôte supérieure à 80 %.
• Utilisez cAdvisor ou Prometheus pour collecter les métriques des conteneurs.
• Effectuez des examens de capacité après chaque version majeure.
• Documentez la base de référence et l’utilisation maximale attendue de chaque service.

Signaux de mise à l’échelle et planification des capacités

Savoir quand mettre à l’échelle fait partie de la planification des capacités. Surveillez ces signaux :

• Utilisation CPU élevée et constante (> 80 % de la limite) sur plusieurs jours.
• Utilisation mémoire approchant la limite avec des OOM kills fréquents.
• Augmentation des temps de réponse ou des taux d’erreur.
• Hôte à court de ressources (charge moyenne élevée, mémoire libre faible).

Lors de la mise à l’échelle, considérez à la fois les approches verticale (augmenter les limites) et horizontale (ajouter des répliques). Pour les services avec état comme les bases de données, la mise à l’échelle verticale peut être plus facile ; pour les applications web sans état, la mise à l’échelle horizontale avec un équilibreur de charge est courante.

Conclusion

La planification des capacités Docker est une discipline continue, pas une tâche ponctuelle. Commencez par un inventaire clair de votre environnement, définissez des limites conservatrices, vérifiez-les sous charge simulée et surveillez les écarts. Utilisez la liste de contrôle pour examiner régulièrement la capacité et ayez toujours un plan de retour en arrière. En suivant les exemples pratiques de ce guide, vous pouvez éviter les pièges courants liés aux ressources et maintenir des services conteneurisés fiables.

Prochaines étapes :

• Exécutez l’inventaire de la version et de l’environnement sur un hôte.
• Définissez des limites CPU et mémoire sur votre conteneur le plus critique.
• Vérifiez les limites avec docker inspect et docker stats.
• Simulez un pic de mémoire ou de CPU pour observer le comportement.
• Documentez votre base de référence et établissez une routine de surveillance.