Planification de capacité pour le déploiement en production avec Docker Compose : guide pratique

Apprenez à estimer les ressources, définir des limites, planifier la mise à l'échelle et gérer les risques de croissance pour les déploiements en production avec Docker Compose à l'aide de commandes concrètes, d'étapes de vérification et de stratégies de retour en arrière.

Introduction

Docker Compose est un moyen courant de définir et d'exécuter des applications multi-conteneurs. En développement, il fonctionne bien avec les paramètres par défaut. En production, toutefois, les paramètres par défaut peuvent entraîner un épuisement des ressources, une dégradation des performances et des pannes. La planification de capacité est le processus d'estimation des ressources informatiques dont votre application a besoin en charge normale et en pointe, et la configuration de Docker Compose pour appliquer ces limites en toute sécurité.

Cet article fournit des conseils pratiques pour la planification de capacité avec Docker Compose en production. Il couvre l'inventaire de l'environnement, la configuration sûre des limites de ressources, les méthodes de vérification, les modes de défaillance, les procédures de récupération, une liste de contrôle des opérations et les pièges courants. En suivant ces étapes, vous pouvez éviter les pièges courants et garantir que votre déploiement est à la fois efficace et résilient.

La planification de capacité n'est pas une tâche ponctuelle. Elle doit être revue à mesure que votre application évolue, que les schémas de trafic changent et que l'infrastructure est mise à jour. Ce guide vous donne les outils pour planifier systématiquement et ajuster en toute confiance.

Inventaire des versions et de l'environnement

Avant de définir des limites de ressources, vous devez avoir une image claire de votre environnement. Cela inclut les versions de Docker et Docker Compose, le système d'exploitation hôte, les ressources matérielles et l'architecture de l'application.

Exécutez les commandes suivantes pour connaître les versions :

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

Exemple de sortie attendue :

Docker version 24.0.5, build ced0996
docker compose version v2.20.2

Notez que Docker Compose V2 est un plugin, et la commande est docker compose (sans trait d'union). L'ancienne V1 utilise docker-compose. Ce guide suppose l'utilisation de V2.

Vérifiez les ressources de l'hôte avec :

free -h
nproc

Exemple de sortie :

              total        used        free      shared  buff/cache   available
Mem:           15Gi       2.1Gi        12Gi       0.0Ki       1.2Gi        13Gi
Swap:         2.0Gi          0B       2.0Gi
4

Cela montre 4 CPU et 15 Gio de RAM. Toute la planification des ressources doit tenir dans ces limites hôte, en laissant une marge pour le système d'exploitation et Docker lui-même. Une règle courante est de réserver au moins 20 % de la mémoire totale et un CPU complet pour le système hôte et la surcharge du démon Docker.

Inspectez vos conteneurs actuels, le cas échéant :

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

Listez les images et leurs tailles :

docker images --format 'table {{.Repository}}:{{.Tag}}\t{{.Size}}'

Documentez la topologie : quels services s'exécutent sur quels ports, leurs dépendances et les systèmes externes. Cet inventaire guidera vos calculs de capacité.

Par exemple, une pile d'application web typique pourrait avoir :

Vérifiez également l'espace disque et les capacités d'E/S de l'hôte, car les journaux des conteneurs et le stockage de la base de données peuvent consommer des ressources importantes.

df -h
iostat -x 1 3

Chemin de configuration sûr

Une fois l'inventaire de l'environnement terminé, vous pouvez définir des limites de ressources sûres dans votre fichier Compose. Les limites de ressources empêchent un conteneur de consommer toutes les ressources de l'hôte et de provoquer une instabilité du système. Utilisez la section deploy.resources, qui est respectée par Docker Compose V2 lors du déploiement sur un nœud unique.

Pour chaque service, définissez des limites (maximum autorisé) et des réservations (minimum garanti). Un point de départ sûr est de limiter chaque service à une fraction des ressources totales de l'hôte. Par exemple, sur un hôte avec 4 CPU et 16 Go de RAM, vous pourriez allouer :

• Service web : 1 CPU, 512 Mo de RAM
• Base de données : 2 CPU, 4 Go de RAM
• Cache : 0,5 CPU, 256 Mo de RAM

Exemple d'extrait Compose :

services:
  web:
    image: nginx:1.25
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
        reservations:
          cpus: '0.5'
          memory: 256M
  db:
    image: postgres:15
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G
        reservations:
          cpus: '1.0'
          memory: 2G

Remarque : cpus est une valeur de chaîne avec des guillemets. La mémoire peut être spécifiée en octets, kilooctets (K), mégaoctets (M) ou gigaoctets (G).

Pour appliquer, utilisez docker compose up -d après avoir modifié le fichier. Vérifiez ensuite que les limites sont définies :

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

Sortie attendue (NanoCpus est en unités de 1e-9 CPU) :

1000000000 536870912

Cela confirme 1 CPU et 512 Mo de limite. Ajustez les limites en fonction de l'utilisation mesurée (voir la section Vérification).

Lors de la définition des limites, tenez compte des éléments suivants :

• Laissez une marge : Assurez-vous que la somme de toutes les limites de service ne dépasse pas 80 % des ressources de l'hôte.
• Réservations vs limites : Les réservations garantissent un minimum, ce qui peut améliorer l'ordonnancement dans Swarm mais sont informatives sur un nœud unique.
• Connaissance de l'application : Les bases de données ont souvent besoin de plus de mémoire ; les serveurs web sans état peuvent fonctionner avec moins.

Vérification et diagnostics

Après avoir appliqué les limites de ressources, vérifiez qu'elles sont effectives et que l'application fonctionne comme prévu. Utilisez les commandes de statistiques intégrées de Docker pour observer la consommation de ressources.

Surveillez l'utilisation en direct :

docker stats --no-stream

Exemple de sortie :

CONTAINER ID   NAME      CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
abcd1234efgh   web       0.50%     45MiB / 512MiB        8.79%     1.2kB / 2.3kB     0B / 0B           5
ijkl5678mnop   db        2.10%     1.2GiB / 4GiB         30.00%    5.4kB / 6.7kB     10MB / 20MB       27

Métriques clés : pourcentage CPU relatif aux CPU alloués, utilisation de la mémoire par rapport à la limite, et E/S. Si un conteneur atteint constamment sa limite de mémoire, il peut être tué par le tueur OOM. Pour vérifier les événements OOM, inspectez l'état du conteneur :

docker inspect web --format '{{.State.OOMKilled}}'

Normalement, false. Si true, le conteneur a été tué en raison de la limite de mémoire. Augmentez la limite ou optimisez l'application.

Vérifiez les journaux du conteneur pour les erreurs :

docker logs web --tail 50

Vérifiez également que l'application répond correctement sous charge. Utilisez un outil comme ab ou wrk pour générer du trafic de test. Par exemple, avec ab :

ab -n 1000 -c 10 http://localhost/

Observez les temps de réponse et les taux d'erreur. Par exemple, une sortie de ab pourrait montrer :

Requests per second:    150.23 [#/sec] (mean)
Time per request:       6.657 [ms] (mean)
Failed requests:        0

Si les performances se dégradent, ajustez les limites en conséquence. De plus, vous pouvez inspecter directement les métriques cgroup :

cat /sys/fs/cgroup/memory/docker/<container-id>/memory.stat
cat /sys/fs/cgroup/cpu/docker/<container-id>/cpu.stat

Ces fichiers montrent des statistiques détaillées de mémoire et d'étranglement CPU, aidant à diagnostiquer des problèmes subtils.

Modes de défaillance et récupération

Les limites de ressources peuvent provoquer des défaillances si elles sont trop basses. Les modes de défaillance courants incluent les tueries OOM, l'étranglement CPU et les délais d'attente de l'application. Prévoyez-les et sachez comment récupérer.

Épuisement de la mémoire

Un conteneur dépassant sa limite de mémoire est tué par le tueur OOM du noyau. Les symptômes incluent des redémarrages brusques du conteneur et un statut OOMKilled à true. Récupération : augmentez la limite de mémoire dans le fichier Compose et redémarrez le service.

docker compose up -d --force-recreate web

Pour éviter la récurrence, surveillez les tendances d'utilisation de la mémoire et définissez des limites avec une marge. Par exemple, si votre conteneur web atteint un pic de 400 Mo, définissez une limite de 512 Mo ou plus.

Étranglement CPU

Si un conteneur utilise plus de CPU que sa limite, le noyau l'étrangle, provoquant une réponse lente. Vérifiez les métriques d'étranglement CPU via docker stats ou les fichiers cgroup. Récupération : augmentez la limite CPU ou optimisez le code.

Pour voir l'étranglement, exécutez :

docker stats --no-stream --format 'table {{.Name}}\t{{.CPUPerc}}'

Et inspectez :

cat /sys/fs/cgroup/cpu/docker/<container-id>/cpu.stat

Recherchez nr_throttled en augmentation. Si c'est le cas, augmentez la limite CPU.

Épuisement de l'espace disque

Les conteneurs écrivant des journaux ou des données peuvent remplir le disque hôte. Surveillez l'utilisation du disque avec df -h. Configurez la rotation des journaux dans Compose :

services:
  web:
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Pour les conteneurs de base de données, assurez-vous que les volumes de données ont une capacité suffisante et surveillez leur croissance.

Stratégie de retour en arrière

Conservez les versions précédentes du fichier Compose (par exemple, en utilisant des tags git). Pour revenir en arrière sur les changements de ressources, revenez au fichier précédent et redéployez.

git checkout tags/v1.0 -- docker-compose.yml
docker compose up -d

Après la récupération, vérifiez avec docker stats et les contrôles de santé de l'application.

Liste de contrôle des opérations

Utilisez la liste de contrôle suivante pour la gestion continue de la capacité. Attribuez un responsable pour chaque élément (par exemple, ingénieur DevOps ou chef d'équipe) et la fréquence de révision.

Des éléments supplémentaires spécifiques à votre application peuvent être nécessaires. Par exemple, si vous utilisez un service de base de données managé, incluez une vérification de son stockage et de ses limites de connexion.

Pièges courants et comment les éviter

La planification de capacité avec Docker Compose échoue souvent de manière prévisible. Voici les pièges courants, pourquoi ils se produisent et comment les éviter ou s'en remettre.

Ignorer les limites au niveau de l'hôte

Pourquoi cela arrive : Les administrateurs se concentrent sur les limites des conteneurs mais oublient que l'hôte lui-même a des ressources finies. Si la somme des limites des conteneurs dépasse la capacité de l'hôte, l'hôte peut ralentir ou devenir insensible.

Comment éviter : Calculez toujours l'allocation totale des ressources. Assurez-vous que la somme des limits pour tous les services ne dépasse pas 80 % des ressources de l'hôte. Laissez le reste pour le système d'exploitation et la surcharge Docker.

Récupération : Réduisez les limites de certains services, ou ajoutez plus de ressources hôte (mise à l'échelle verticale).

Définir des limites trop basses

Pourquoi cela arrive : Pour être sûr, vous définissez des limites conservatrices, mais l'application a besoin de plus pendant les pics de charge.

Comment éviter : Utilisez des tests de charge pour déterminer les besoins réalistes. Définissez des limites au moins 20 à 30 % au-dessus de l'utilisation de pointe observée.

Récupération : Surveillez les tueries OOM et l'étranglement. Augmentez progressivement les limites et redéployez.

Oublier la rotation des journaux

Pourquoi cela arrive : Le pilote de journalisation par défaut de Docker (json-file) ne fait pas tourner les journaux par défaut, donc les journaux peuvent croître indéfiniment et consommer de l'espace disque.

Comment éviter : Configurez la rotation des journaux dans le fichier Compose comme montré précédemment.

Récupération : Si le disque est plein, tronquez manuellement les journaux : truncate -s 0 /var/lib/docker/containers/<container-id>/<container-id>-json.log, puis ajoutez la configuration de rotation.

Ne pas tenir compte de la croissance de la base de données

Pourquoi cela arrive : Vous planifiez pour la taille initiale des données mais oubliez que les données s'accumulent avec le temps.

Comment éviter : Surveillez régulièrement la taille de la base de données. Définissez des alertes lorsque l'utilisation du disque dépasse 70 %. Planifiez l'archivage des données ou la mise à l'échelle.

Récupération : Attachez un volume plus grand ou passez à un service de base de données externe.

Négliger l'étranglement CPU

Pourquoi cela arrive : L'étranglement CPU est subtil ; le conteneur s'exécute mais plus lentement que prévu. Il peut être confondu avec une inefficacité de l'application.

Comment éviter : Surveillez nr_throttled dans les statistiques cgroup. Définissez des limites CPU basées sur l'utilisation réelle avec une marge.

Récupération : Augmentez la limite CPU ou optimisez le code de l'application.

Utiliser la syntaxe Compose V1

Pourquoi cela arrive : Certaines équipes utilisent encore docker-compose (V1), qui ne prend pas en charge la section deploy.resources de la même manière.

Comment éviter : Migrez vers Docker Compose V2 (docker compose). Vérifiez avec docker compose version.

Récupération : Si bloqué avec V1, utilisez les propriétés de service de niveau supérieur mem_limit et cpus, mais notez qu'elles sont moins flexibles.

Conclusion

La planification de capacité pour les déploiements en production avec Docker Compose est essentielle pour la stabilité et l'efficacité des coûts. En inventoriant votre environnement, en définissant des limites de ressources explicites, en vérifiant avec des métriques observables, en vous préparant aux modes de défaillance, en suivant une liste de contrôle reproductible et en évitant les pièges courants, vous pouvez gérer la capacité de manière proactive.

Prochaines étapes : Appliquez ce guide à un petit service pilote mesurable, surveillez son comportement et étendez progressivement à d'autres services. Revoyez régulièrement votre plan de capacité à mesure que votre application se développe. Avec ces pratiques, vous pouvez éviter les pièges courants liés aux ressources et garantir que votre déploiement Docker Compose fonctionne correctement en production.

La planification de capacité est une discipline continue. Documentez vos décisions, mesurez l'utilisation réelle et ajustez les limites si nécessaire. Avec une approche systématique, vous pouvez maintenir un déploiement résilient et efficace.