Planification de capacité des images Docker : guide pratique de mise en œuvre

Introduction

Les images Docker sont les éléments constitutifs des applications conteneurisées, mais elles peuvent croître en taille et en nombre sans avertissement. Sans plan de capacité, vous risquez de vous retrouver avec un stockage de registre saturé, des déploiements ralentis et des développeurs incapables de pousser de nouvelles images. Ce guide propose une approche pratique de la planification de la capacité des images Docker, notamment l’estimation du stockage, la définition de limites, la surveillance de la croissance et la planification d’opérations sûres. Nous utiliserons des commandes et des exemples concrets que vous pourrez adapter à votre environnement.

Inventaire des versions et de l’environnement

Avant de planifier la capacité, vous devez connaître votre environnement Docker actuel. Cela inclut la version de Docker, le pilote de stockage, le type de registre et les images actuellement utilisées.

Version de Docker et pilote de stockage

Exécutez les commandes suivantes pour obtenir la version de Docker et le pilote de stockage :

docker version --format '{{.Server.Version}}'
docker info --format 'Storage Driver: {{.Driver}}'

Exemple de sortie :

20.10.12
Storage Driver: overlay2

Le pilote de stockage affecte la manière dont les images sont stockées et dédupliquées. overlay2 est courant et efficace pour la plupart des distributions Linux. Si vous utilisez un autre pilote, notez ses caractéristiques.

Registre et inventaire des images

Listez toutes les images sur un hôte :

docker images

Exemple de sortie :

REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
myapp        latest    abc123def456   2 hours ago    450MB
myapp        v1.0      def456abc123   1 week ago     445MB
nginx        latest    nginx123abc    2 weeks ago    142MB

Pour obtenir un résumé de l’utilisation totale du disque par les images Docker :

docker system df

Sortie :

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          12        3         4.2GB     2.1GB (50%)
Containers      5         2         200MB     150MB (75%)
Local Volumes   2         1         500MB     250MB (50%)
Build Cache     0         0         0B        0B

Ceci montre la taille totale des images et la quantité récupérable. Dans cet exemple, vous pourriez libérer 2,1 Go en supprimant les images inutilisées.

Prérequis

• Docker installé (version 20.x ou supérieure pour la plupart des fonctionnalités).
• Accès à un registre Docker si vous utilisez un registre distant (par exemple, Docker Hub, AWS ECR ou un registre privé).
• Espace disque suffisant pour contenir les images et les frais généraux (généralement 20 à 30 % de plus pour le cache de construction et les métadonnées).
• Compréhension du cycle de vie des images de votre application.

Chemin de configuration sécurisé

Maintenant, mettons en œuvre des mesures de planification de capacité. L’essentiel est de commencer par un pilote restreint et mesurable : choisissez une application ou un petit ensemble d’images, et appliquez les techniques suivantes.

1. Optimiser le Dockerfile pour réduire la taille de l’image

Des images plus petites consomment moins de stockage et se transfèrent plus rapidement. Utilisez des constructions multi-étapes, des images de base minimales et supprimez les fichiers inutiles.

Exemple de Dockerfile original :

FROM node:14
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build
CMD ["npm", "start"]

Version optimisée utilisant multi-étapes et alpine :

# Étape de construction
FROM node:14-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Étape de production
FROM node:14-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY package*.json ./
RUN npm install --only=production
CMD ["npm", "start"]

Construisez l’image optimisée et comparez les tailles :

docker build -t myapp:optimized .
docker images myapp

Sortie avant et après :

myapp   latest     450MB
myapp   optimized  120MB

Une réduction de plus de 70 %.

2. Définir des politiques de rétention des images

Supprimez automatiquement les images anciennes ou non étiquetées pour éviter l’accumulation. Utilisez docker image prune avec des filtres.

Pour supprimer les images sans étiquette :

docker image prune

Pour supprimer toutes les images non utilisées par un conteneur (y compris celles étiquetées) :

docker image prune -a

Exemple de sortie :

Deleted Images:
untagged: myapp@sha256:...
deleted: sha256:...
untagged: myapp:v1.0
...
Total reclaimed space: 2.1GB

Planifiez cette commande comme une tâche cron ou utilisez des politiques au niveau du registre (par exemple, les politiques de cycle de vie AWS ECR) pour les registres distants.

Exemple de politique de cycle de vie ECR en JSON :

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "Conserver les 10 dernières images",
      "selection": {
        "tagStatus": "any",
        "countType": "imageCountMoreThan",
        "countNumber": 10
      },
      "action": {
        "type": "expire"
      }
    }
  ]
}

Cette politique expirerait toutes les images sauf les 10 plus récentes du dépôt.

3. Surveiller et limiter le stockage du registre

Si vous gérez un registre privé, définissez des quotas de stockage. Par exemple, avec Docker Registry 2.0, vous pouvez utiliser la configuration pour limiter le stockage ou vous appuyer sur des quotas de système de fichiers sous-jacents.

Si vous utilisez un fournisseur cloud, configurez des alertes dans CloudWatch ou Stackdriver lorsque le stockage du registre approche d’un seuil.

Exemple : commande AWS CLI pour vérifier la taille d’un dépôt ECR (utiliser aws ecr describe-images est complexe ; voici une approche simplifiée avec un script).

aws ecr describe-repositories --query 'repositories[].[repositoryName, repositoryUri]'

Pour obtenir la taille d’un dépôt, vous devrez peut-être utiliser un script personnalisé qui additionne les tailles des images à partir de describe-images.

4. Utiliser stratégiquement l’étiquetage des images

Adoptez une stratégie d’étiquetage qui soutient la gestion de capacité. Par exemple, utilisez des étiquettes immuables pour les versions (par exemple, v1.2.3) et évitez d’utiliser latest en production. Cela empêche les écrasements inattendus et permet un meilleur suivi.

Exemple :

docker tag myapp:latest myapp:v1.2.3
docker push myapp:v1.2.3

Ensuite, vous pouvez supprimer en toute sécurité les anciennes étiquettes après une certaine période.

Vérification et diagnostic

Après avoir mis en œuvre ces mesures, vérifiez qu’elles fonctionnent comme prévu.

Vérifier les tailles des images

Surveillez régulièrement les tailles des images. Utilisez un script pour lister les images et les trier par taille :

docker images --format '{{.Repository}}:{{.Tag}} {{.Size}}' | sort -rh -k2

Sortie :

myapp:latest   450MB
myapp:v1.0     445MB
nginx:latest   142MB
...

Cela permet d’identifier les images volumineuses qui pourraient nécessiter une optimisation.

Vérifier l’espace récupérable

Exécutez docker system df pour voir l’espace récupérable :

docker system df

Si vous avez effectué une suppression, la valeur récupérable devrait être plus faible.

Tester le temps de tirage d’une image

Mesurez le temps nécessaire pour tirer une image sur un nœud frais, ce qui indique le temps de transfert et peut affecter la mise à l’échelle.

time docker pull myapp:latest

Sortie :

real    0m12.345s
user    0m0.123s
sys     0m0.456s

Si ce temps est trop long, envisagez un registre local ou un réseau de distribution de contenu.

Surveiller l’API du registre

Pour un registre privé, vérifiez l’API pour l’utilisation du stockage (si disponible). Pour Docker Hub, vous pouvez utiliser l’API pour obtenir les détails du dépôt, mais il peut y avoir des limites de débit.

Exemple de commande curl vers l’API Docker Hub :

curl -s https://hub.docker.com/v2/repositories/library/nginx/ | jq .pull_count

La sortie affiche le nombre de tirages, ce qui peut indiquer la popularité mais pas la taille.

Valider la politique de rétention

Après avoir configuré une politique de cycle de vie (par exemple, dans ECR), validez que les images expirent comme prévu. Vous pouvez vérifier en listant les images après la période d’évaluation de la politique.

Modes de défaillance et récupération

Les échecs de planification de capacité peuvent entraîner plusieurs problèmes. Voici les modes de défaillance courants et comment les récupérer.

Disque plein sur l’hôte Docker

Symptôme : les commandes Docker échouent avec « plus d’espace disponible sur le périphérique » ou les tirages sont bloqués.

Récupération :

• Identifier les fichiers volumineux : du -sh /var/lib/docker
• Supprimer les images inutilisées : docker image prune -a
• Si nécessaire, supprimer les conteneurs arrêtés et les volumes : docker system prune
• Étendre le disque ou déplacer le répertoire de données Docker vers un disque plus grand.

Exemple de déplacement du répertoire de données Docker (nécessite l’arrêt de Docker) :

sudo systemctl stop docker
sudo rsync -aP /var/lib/docker/ /mnt/large/docker/
sudo rm -rf /var/lib/docker
sudo ln -s /mnt/large/docker /var/lib/docker
sudo systemctl start docker

Registre hors stockage

Symptôme : le push échoue avec « refusé : accès à la ressource demandée refusé » ou « hors espace ».

Récupération :

• Pour un registre auto-hébergé, étendre le stockage ou supprimer les couches non référencées.
• Pour un registre cloud, augmenter le quota de stockage (peut entraîner des coûts) ou nettoyer les anciennes images à l’aide de politiques de cycle de vie.

Tirages d’images lents

Symptôme : les déploiements prennent plus de temps et les nouveaux nœuds mettent des minutes à démarrer.

Récupération :

• Optimiser la taille de l’image comme indiqué précédemment.
• Utiliser un miroir de registre local ou un proxy de cache.
• Pour Kubernetes, utiliser le pré-tirage d’images sur les nœuds.

Étiquetage incorrect entraînant des écrasements

Symptôme : la production exécute soudainement un code différent parce que latest a été écrasé.

Récupération :

• Toujours utiliser des étiquettes immuables pour la production.
• Revenir en arrière en déployant l’image étiquetée précédente.
• Mettre en place une politique selon laquelle seul le pipeline CI/CD peut pousser vers les étiquettes de production.

Plan de retour en arrière

Ayez toujours un plan de retour en arrière pour tout changement de configuration. Par exemple, si vous avez mis en œuvre une nouvelle politique de rétention qui supprime trop d’images, vous devrez peut-être annuler la politique et restaurer les images à partir de sauvegardes (si disponibles). Conservez une sauvegarde des images critiques en les poussant vers un dépôt séparé ou en les archivant dans un service de stockage.

Pièges courants et erreurs

Même avec une planification minutieuse, les équipes rencontrent souvent ces problèmes. Comprendre pourquoi ils se produisent et comment les éviter peut économiser du temps et du stockage.

Ignorer la croissance du cache de construction

Pourquoi cela arrive : le cache de construction Docker s’accumule sur les serveurs de construction, surtout lorsque les constructions sont fréquentes et que les Dockerfiles changent.

Comment l’éviter : purgez régulièrement le cache de construction à l’aide de docker builder prune selon un calendrier. Définissez une limite de taille de cache de construction dans la configuration du démon Docker si votre environnement le permet.

Abuser de l’étiquette latest

Pourquoi cela arrive : les développeurs utilisent par défaut latest pour plus de commodité, ce qui conduit à un contenu d’image imprévisible et à des difficultés de retour en arrière.

Comment l’éviter : imposez des étiquettes immuables pour les versions. Utilisez une convention d’étiquetage comme major.minor.patch ou commit-sha. Bloquez les poussées vers latest dans les registres de production à l’aide de politiques.

Négliger les constructions multi-étapes

Pourquoi cela arrive : les équipes s’en tiennent aux constructions à une seule étape parce qu’elles fonctionnent, sans réaliser l’impact sur la taille.

Comment l’éviter : adoptez des constructions multi-étapes pour tous les nouveaux projets. Passez en revue les Dockerfiles existants et refactorisez si possible. Montrez la différence de taille aux parties prenantes pour justifier l’effort.

Sous-estimer la prolifération des images

Pourquoi cela arrive : chaque branche de fonctionnalité ou construction de test crée de nouvelles images sans stratégie de nettoyage.

Comment l’éviter : mettez en place des politiques de cycle de vie de registre dès le premier jour. Utilisez le nettoyage automatique des étiquettes pour les constructions temporaires. Surveillez le nombre d’images et définissez des alertes lorsque les seuils sont dépassés.

Ignorer les mises à jour des images de base

Pourquoi cela arrive : les images de base sont rarement mises à jour, ce qui conduit à des images obsolètes et potentiellement plus volumineuses.

Comment l’éviter : reconstruisez régulièrement les images avec des images de base mises à jour. Utilisez des outils comme Dependabot ou Renovate pour automatiser les mises à jour des images de base dans les Dockerfiles.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour la gestion continue de la capacité. Attribuez chaque élément à un propriétaire responsable unique et définissez une fréquence de révision.

Conclusion

La planification de la capacité des images Docker est essentielle pour maintenir un environnement de conteneurs sain. En inventoriant vos images actuelles, en optimisant les Dockerfiles, en mettant en œuvre des politiques de rétention et en surveillant l’utilisation, vous pouvez prévenir l’épuisement du stockage et les goulots d’étranglement des déploiements. Commencez par un pilote restreint et mesurable : choisissez une application, appliquez les techniques de ce guide et vérifiez les résultats. Ensuite, étendez à l’ensemble de votre parc. Utilisez la liste de contrôle des opérations pour garder le contrôle et ajuster à mesure que vos besoins évoluent. Avec ces pratiques, vous pouvez vous assurer que vos images Docker restent efficaces, gérables et rentables.

Résumé des commandes clés

En suivant ce guide, vous pouvez établir une stratégie solide de planification de capacité pour les images Docker.