Lister les images locales (docker images / docker image ls)
Découvrez comment visualiser, filtrer et analyser efficacement vos images Docker locales. Maîtrisez les commandes docker images et docker image ls pour une gestion optimale de votre environnement Docker.
Comprendre le système de stockage local des images Docker
Le système de stockage local des images Docker repose sur une architecture sophistiquée conçue pour optimiser l'utilisation de l'espace disque tout en maintenant des performances élevées. Sur un système Linux typique, Docker stocke par défaut ses données dans le répertoire /var/lib/docker, avec les images principalement localisées dans le sous-répertoire /var/lib/docker/image/. Cette structure contient les métadonnées des images et références vers les couches réelles stockées dans /var/lib/docker/overlay2/ (pour le driver de stockage overlay2, le plus couramment utilisé). Sur Windows et macOS, cette hiérarchie existe dans un système de fichiers virtualisé au sein de la machine virtuelle légère qui exécute le daemon Docker.
Chaque image Docker est composée de plusieurs couches empilées grâce au système de fichiers en couches (layered filesystem), généralement implémenté via OverlayFS sur les systèmes Linux modernes. Cette architecture permet un stockage remarquablement efficient : lorsque plusieurs images partagent des couches communes – par exemple, si elles sont basées sur la même image de base ou utilisent des composants similaires – ces couches ne sont stockées qu'une seule fois physiquement sur le disque. Docker maintient un système de références qui permet à chaque image de connaître les couches qui la composent sans duplication inutile des données. Cette mutualisation explique pourquoi l'espace disque total utilisé par vos images est généralement bien inférieur à la somme des tailles individuelles affichées par `docker images`.
Les identifiants d'images et leur système d'indexation représentent un aspect crucial pour comprendre comment Docker gère ses ressources localement. Chaque image est identifiée par un hash SHA256 unique, généralement abrégé aux 12 premiers caractères dans l'interface utilisateur. Ce hash est calculé à partir du contenu exact de l'image, garantissant qu'une modification, même mineure, génère un identifiant totalement différent. Parallèlement, le système de tags permet des références plus conviviales (comme ubuntu:20.04 ou nginx:latest) qui pointent vers ces identifiants cryptographiques. Ces deux systèmes coexistent dans le stockage local : les identifiants assurent l'intégrité et l'unicité absolues, tandis que les tags offrent une interface humainement compréhensible.
Le cycle de vie d'une image dans le stockage local suit plusieurs étapes bien définies. Une image peut être téléchargée depuis un registry externe via `docker pull`, créée localement via `docker build` ou `docker commit`, ou encore importée depuis une archive avec `docker load`. Une fois présente localement, elle reste disponible jusqu'à sa suppression explicite par `docker rmi` ou `docker image prune`. Toutefois, même après cette suppression apparente, certaines couches peuvent persister si elles sont partagées avec d'autres images encore présentes. Cette persistance optimise l'espace disque mais peut parfois complexifier la compréhension de l'utilisation réelle des ressources de stockage.
La gouvernance efficace du stockage local devient particulièrement importante à mesure que votre environnement Docker s'enrichit. Sans politique explicite de gestion, les images s'accumulent progressivement, consommant un espace disque précieux. Les images abandonnées (dangling), qui ne sont plus référencées par aucun tag mais dont les couches persistent, représentent un défi particulier puisqu'elles n'apparaissent pas clairement dans les listings standard. La commande `docker system df` s'avère précieuse pour obtenir une vision d'ensemble de l'utilisation de l'espace, distinguant les espaces utilisés par les images, les conteneurs et les volumes, et identifiant les ressources potentiellement récupérables.
Syntaxe et options fondamentales des commandes de listage
Docker propose deux commandes équivalentes pour lister les images stockées localement : la commande historique `docker images` et sa version plus récente et plus cohérente avec la nomenclature moderne `docker image ls`. Ces deux commandes produisent par défaut une sortie identique organisée en tableau, avec cinq colonnes d'informations essentielles : REPOSITORY (le nom de l'image, souvent sous la forme namespace/repository), TAG (l'identifiant humainement lisible de la version), IMAGE ID (l'identifiant unique abrégé), CREATED (la date de création) et SIZE (la taille virtuelle). Cette présentation structurée offre un aperçu immédiat de votre bibliothèque d'images locale, facilitant l'identification des ressources disponibles pour instancier des conteneurs.
L'option `--all` (ou `-a`) enrichit significativement la sortie en incluant les images intermédiaires normalement masquées dans l'affichage par défaut. Ces images, généralement créées lors des étapes de construction (`docker build`), n'ont pas de tag explicite et apparaissent avec un repository et un tag "
Le filtrage des résultats via l'option `--filter` (ou `-f`) permet d'affiner précisément la liste des images affichées selon des critères variés. Cette fonctionnalité puissante accepte des expressions au format `key=value` qui peuvent être combinées pour des requêtes complexes. Par exemple, `docker images --filter reference=ubuntu --filter before=nginx:latest` affichera toutes les images Ubuntu créées avant l'image nginx:latest. Les filtres les plus couramment utilisés incluent : `dangling=true/false` pour les images abandonnées sans tag, `reference=pattern` pour filtrer par nom/tag, `before/since=image` pour des critères temporels, et `label=key=value` pour sélectionner des images selon leurs métadonnées. Cette capacité de filtrage s'avère particulièrement précieuse dans les environnements à grande échelle ou pour automatiser des opérations de maintenance ciblées.
La personnalisation du format de sortie via l'option `--format` transforme radicalement la présentation des informations, permettant une adaptation précise à vos besoins spécifiques. Basée sur les templates Go, cette fonctionnalité permet d'extraire et d'organiser exactement les données qui vous intéressent. Par exemple, `docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}"` produit un tableau simplifié avec uniquement trois colonnes, tandis que `docker images --format "{{.Repository}}:{{.Tag}} -> {{.Size}}"` génère une liste concise au format personnalisé. Pour les scripts automatisés, `docker images --format "{{json .}}"` retourne chaque image sous forme d'objet JSON complet, facilitant l'intégration avec d'autres outils de traitement. Cette flexibilité de formatage s'avère particulièrement précieuse pour les rapports, les tableaux de bord ou les scripts d'automatisation.
L'option `--quiet` (ou `-q`) réduit drastiquement la verbosité de la commande en retournant uniquement les identifiants d'images (IMAGE ID), sans aucune autre information. Ce mode minimaliste s'avère particulièrement utile dans les scripts shell pour itérer sur toutes les images ou les passer comme arguments à d'autres commandes Docker. Par exemple, `docker rmi $(docker images -q)` supprime toutes les images locales, tandis que `docker images -q --filter dangling=true` extrait uniquement les IDs des images abandonnées pour un nettoyage ciblé. Cette option peut être combinée avec d'autres filtres pour créer des commandes composites puissantes et précises, parfaites pour les workflows d'automatisation ou les tâches de maintenance récurrentes.
L'analyse des tailles d'images nécessite une attention particulière du fait de la nature en couches du stockage Docker. La colonne SIZE affichée par `docker images` représente la taille virtuelle de chaque image, c'est-à-dire la somme des tailles de toutes ses couches. Cependant, en raison du partage des couches entre images, l'espace disque réellement occupé est généralement bien inférieur à la somme de ces tailles individuelles. Pour obtenir une vision plus précise de l'utilisation réelle de l'espace, la commande `docker system df -v` fournit un rapport détaillé distinguant l'espace partagé de l'espace unique à chaque image. Cette nuance s'avère cruciale pour une gestion efficace de l'espace disque, particulièrement dans les environnements aux ressources limitées où l'optimisation du stockage devient prioritaire.
Filtrage avancé et sélection précise des images
Le filtrage par patterns de référence permet une sélection extrêmement flexible des images basée sur leur nom et leur tag. La syntaxe `docker images 'pattern'` ou `docker image ls 'pattern'` accepte des expressions utilisant les caractères génériques standard. Par exemple, `docker images 'python:3*'` affiche toutes les images Python de la version 3, tandis que `docker images '*alpine*'` sélectionne toutes les images contenant "alpine" dans leur nom ou tag. Cette approche par pattern s'avère particulièrement puissante pour naviguer dans des environnements comportant de nombreuses variantes d'images similaires. Pour des besoins encore plus spécifiques, ces patterns peuvent être combinés avec l'option filter : `docker images --filter reference='nginx:*' --filter reference='*:latest'` affiche les images nginx qui ont également un tag latest, illustrant la flexibilité remarquable du système de requêtage.
L'identification des images abandonnées (dangling) représente un cas d'usage particulièrement important pour la maintenance du système. Ces images, qui apparaissent avec `
Le filtrage temporel basé sur les dates de création ou les relations chronologiques entre images offre une dimension supplémentaire pour affiner vos sélections. Les options `--filter before=image:tag` et `--filter since=image:tag` permettent de sélectionner respectivement les images créées avant ou après une image de référence. Par exemple, `docker images --filter since=$(date -d '7 days ago' +%s)` affiche uniquement les images créées durant la semaine écoulée, tandis que `docker images --filter before=myapp:1.0` liste toutes les images antérieures à une version spécifique de votre application. Cette capacité de filtrage chronologique s'avère particulièrement précieuse pour les audits de sécurité, les procédures de mise à jour, ou l'identification d'images potentiellement obsolètes qui pourraient bénéficier d'une reconstruction avec des composants plus récents.
La sélection basée sur les métadonnées et les labels permet un filtrage encore plus sophistiqué, exploitant les informations contextuelles associées aux images. Docker supporte l'ajout de métadonnées arbitraires aux images via l'instruction LABEL dans les Dockerfiles, et ces métadonnées peuvent ensuite servir de critères de filtrage. La commande `docker images --filter label=maintainer=team-backend` affichera uniquement les images maintenues par l'équipe backend, tandis que `docker images --filter label=environment=production` isolera les images destinées à l'environnement de production. Cette approche encourage une organisation structurée de votre bibliothèque d'images, où des conventions systématiques de labellisation facilitent ensuite la gestion, l'audit et l'automatisation des opérations de maintenance ciblées.
Les techniques de combinaison de filtres permettent de construire des requêtes complexes pour répondre à des besoins de sélection précis. Docker traite les filtres multiples avec une logique ET, affinant progressivement l'ensemble des résultats. Par exemple, `docker images --filter reference='nginx:*' --filter before=2023-01-01 --filter label=environment=staging` sélectionnera uniquement les images nginx créées avant 2023 et étiquetées pour l'environnement de staging. Cette capacité de filtrage composé devient particulièrement puissante lorsqu'elle est combinée avec des options de formatage personnalisé, permettant d'extraire exactement les informations pertinentes selon des critères multidimensionnels. Pour les environnements à grande échelle, ces requêtes précises facilitent la création de rapports d'inventaire, l'identification de candidats à l'archivage, ou l'application sélective de politiques de gouvernance.
L'intégration du filtrage avec des outils externes comme `grep`, `awk` ou `jq` étend encore les capacités de sélection au-delà des fonctionnalités natives de Docker. Par exemple, `docker images | grep '^ubuntu' | sort -k2` liste toutes les images Ubuntu triées par tag, tandis que `docker images --format '{{json .}}' | jq 'select(.Size | tonumber > 1000000000)'` identifie les images dépassant 1 GB. Ces pipelines hybrides combinant les filtres Docker natifs avec les outils standard du shell offrent une flexibilité pratiquement illimitée pour interroger et analyser votre inventaire d'images. Cette approche s'avère particulièrement précieuse pour les scripts de maintenance complexes ou les tableaux de bord personnalisés qui nécessitent des extractions de données précises selon des critères spécifiques à votre organisation.
Interprétation des métadonnées et analyse des images
La compréhension des identifiants d'images constitue un prérequis fondamental pour naviguer efficacement dans l'écosystème Docker. Chaque image possède un identifiant unique basé sur un hachage SHA256 de son contenu, généralement présenté sous forme abrégée (les 12 premiers caractères) dans les commandes `docker images` ou `docker image ls`. Il est important de noter que cet identifiant est déterministe : le même contenu produira toujours le même hash, garantissant ainsi l'intégrité et la traçabilité des images. La forme complète de cet identifiant peut être obtenue via `docker images --no-trunc`, révélant sa nature cryptographique. L'identifiant représente l'empreinte digitale immuable de l'image et reste constant même si ses tags sont modifiés, ce qui en fait la référence la plus fiable pour des opérations critiques ou des audits de sécurité.
Le champ CREATED mérite une attention particulière car il peut induire en erreur s'il n'est pas correctement interprété. Contrairement à ce que son nom suggère, cette valeur n'indique pas nécessairement quand l'image a été téléchargée ou créée localement, mais plutôt quand elle a été initialement construite, potentiellement sur un système distant. Pour les images officielles tirées de Docker Hub, cette date peut remonter à plusieurs mois, même si l'image vient d'être téléchargée. Pour obtenir l'historique complet de la construction d'une image, la commande `docker history image:tag` s'avère plus informative, détaillant chaque couche avec sa date de création, sa taille et la commande qui l'a générée. Cette chronologie détaillée permet d'évaluer la fraîcheur relative des différents composants d'une image et d'identifier potentiellement des couches obsolètes nécessitant une mise à jour.
L'analyse approfondie des métadonnées d'une image spécifique s'effectue via la commande `docker image inspect` qui révèle une structure JSON exhaustive contenant toutes les informations disponibles sur l'image. Cette mine d'informations inclut l'architecture cible, les variables d'environnement préconfigurées, les commandes par défaut (CMD et ENTRYPOINT), les volumes déclarés, les ports exposés, et bien d'autres paramètres essentiels à la compréhension du comportement attendu de l'image. Pour extraire une information précise de cette structure complexe, le flag `--format` s'avère particulièrement utile : `docker image inspect --format='{{.Config.Cmd}}' nginx` affiche uniquement la commande par défaut de l'image nginx. Cette capacité d'inspection granulaire facilite l'intégration avec des scripts d'automatisation, des validations de conformité ou des rapports de configuration.
La visualisation de la structure en couches d'une image s'effectue via la commande `docker history` qui décompose l'image en ses constituants élémentaires créés par les différentes instructions du Dockerfile. Cette vue chronologique, de la couche la plus récente (en haut) à la plus ancienne (en bas), offre une compréhension claire de la généalogie de l'image. Par exemple, `docker history --no-trunc nginx:latest` affiche l'historique complet non tronqué de l'image nginx, révélant chaque modification apportée lors de sa construction. Cette visibilité s'avère particulièrement précieuse pour l'optimisation des images (identification des couches volumineuses) ou pour l'audit de sécurité (vérification des commandes exécutées durant la construction).
L'analyse de l'utilisation réelle de l'espace disque nécessite une compréhension nuancée du système de stockage en couches. La commande `docker system df` fournit une vue d'ensemble de l'utilisation des ressources, tandis que `docker system df -v` détaille précisément l'espace occupé par chaque image, distinguant l'espace partagé de l'espace unique. Cette distinction est cruciale car la somme des tailles affichées par `docker images` est généralement bien supérieure à l'espace réellement occupé, en raison du partage efficace des couches communes. Pour une analyse encore plus détaillée, des outils tiers comme docker-slim, dive ou container-diff permettent de visualiser et d'analyser la composition interne des images, identifiant les fichiers volumineux ou les duplications potentielles entre couches, facilitant ainsi l'optimisation ciblée de l'empreinte disque.
La corrélation entre images et conteneurs actifs représente une dimension d'analyse essentielle pour une gestion éclairée de votre environnement Docker. La commande `docker image ls --filter reference=image:tag --format '{{.ID}}'` combinée avec `docker ps --filter ancestor=ID` permet d'identifier tous les conteneurs en cours d'exécution basés sur une image spécifique. Cette information s'avère particulièrement précieuse lors de la planification de maintenance : une image utilisée par de nombreux conteneurs actifs nécessitera une stratégie de mise à jour plus prudente qu'une image sans instanciation active. Pour une vue d'ensemble complète, `docker image inspect --format='{{.RepoTags}} {{.Id}} {{.Size}}'` couplé à des scripts d'analyse peut générer des rapports détaillés croisant utilisation des images, âge, taille et activité des conteneurs associés, offrant ainsi une base solide pour les décisions de gouvernance de votre écosystème Docker.
Stratégies de gestion et maintenance des images locales
L'implémentation d'une politique de tagging cohérente constitue la pierre angulaire d'une gestion efficace des images Docker. Une convention de nommage structurée facilite considérablement l'identification, le filtrage et la gouvernance de votre bibliothèque d'images locale. Pour les applications développées en interne, une approche recommandée combine des éléments informatifs dans le tag : `[version]-[environnement]-[date ou build ID]`, par exemple `myapp:1.2.3-prod-20230415`. Cette stratégie multicouche maintient la traçabilité tout en permettant un filtrage précis via les patterns de recherche. La documentation explicite de cette convention dans un guide d'équipe garantit son adoption cohérente par tous les membres, évitant la prolifération de schémas de nommage divergents qui compliqueraient la maintenance à long terme. Des outils automatisés comme Semantic Release peuvent générer ces tags structurés lors des processus CI/CD, garantissant leur application systématique.
Les stratégies de nettoyage des images inutilisées permettent de maintenir l'efficience du stockage local sans compromettre les opérations critiques. La commande `docker image prune` élimine les images dangling (sans tag), tandis que `docker image prune -a` supprime toutes les images sans conteneur associé. Pour un contrôle plus fin, des approches sélectives peuvent être implémentées via des scripts personnalisés : ```#!/bin/bash# Supprimer les images plus anciennes que 30 jours sans conteneur associédocker images --format "{{.ID}} {{.CreatedAt}}" | \awk '$2 < "'$(date -d '30 days ago' +'%Y-%m-%d')"' {print $1}' | \xargs -r docker image inspect --format="{{if eq (len .RepoTags) 0}}{{.ID}}{{end}}" | \xargs -r docker rmi```. Cette approche granulaire permet d'adapter précisément la politique de rétention à vos besoins spécifiques, préservant les images critiques tout en récupérant l'espace occupé par les ressources obsolètes.
L'organisation par projets ou équipes via les namespaces et préfixes facilite la gestion dans les environnements multi-projets ou multi-équipes. En adoptant une convention où chaque image commence par un identifiant de projet ou d'équipe, par exemple `frontend/webapp` ou `backend/api`, vous créez une ségrégation logique qui simplifie la gestion collective. Les commandes comme `docker images frontend/*` permettent alors d'isoler instantanément toutes les images d'un projet spécifique pour analyse ou maintenance. Cette segmentation logique peut être renforcée par des labels standardisés (via LABEL dans les Dockerfiles) contenant des métadonnées comme le propriétaire, le cycle de vie attendu, ou les coordonnées de support. Cette richesse métadonnée transforme votre registre d'images en une ressource organisationnelle structurée plutôt qu'une simple collection technique.
L'automatisation de l'inventaire et du reporting apporte une dimension proactive à la gestion des images locales. Des scripts périodiques peuvent générer des rapports détaillés sur l'état de votre bibliothèque d'images, identifiant automatiquement les candidats potentiels pour archivage, mise à jour ou suppression : ```#!/bin/bash# Générer un rapport CSV d'inventaire des imagesecho "REPOSITORY,TAG,SIZE,CREATED,CONTAINERS,VULNERABILITIES" > image_inventory.csvdocker images --format "{{.Repository}},{{.Tag}},{{.Size}},{{.CreatedAt}}" | \while read line; do # Compter les conteneurs utilisant cette image img_id=$(docker images --format "{{.ID}}" --filter reference=$(echo $line | cut -d',' -f1,2 | tr ',' ':')) container_count=$(docker ps -a --filter ancestor=$img_id --format "{{.ID}}" | wc -l) # Intégration optionnelle avec scanner de vulnérabilités vulns=$(trivy image --format json $(echo $line | cut -d',' -f1,2 | tr ',' ':') | jq '.Results[].Vulnerabilities | length' 2>/dev/null || echo "N/A") echo "$line,$container_count,$vulns" >> image_inventory.csvdone```. Ces rapports peuvent alimenter des tableaux de bord de gouvernance, facilitant les décisions basées sur des données objectives plutôt que des impressions subjectives.
L'implémentation de limites et quotas d'utilisation devient essentielle dans les environnements partagés ou aux ressources limitées. Bien que Docker lui-même n'offre pas nativement de système de quotas pour le stockage d'images, plusieurs approches peuvent être combinées pour obtenir un résultat similaire. La configuration du driver de stockage avec des limites explicites via `dm.basesize` pour devicemapper ou l'utilisation de filesystems avec support de quotas comme XFS peut imposer des contraintes globales. Pour une approche plus granulaire, des scripts de surveillance peuvent générer des alertes lorsque l'utilisation de l'espace par les images dépasse des seuils prédéfinis, déclenchant des actions de nettoyage automatiques ou notifiant les administrateurs. Dans les environnements d'entreprise, ces politiques de quotas devraient être documentées et communiquées clairement aux équipes, incluant les procédures de demande d'exemption pour les cas exceptionnels.
Les stratégies de migration et de sauvegarde des images essentielles représentent un aspect souvent négligé mais critique de la gestion à long terme. Pour les images stratégiques dont dépendent des applications critiques, une politique de sauvegarde explicite devrait être mise en place : ```#!/bin/bash# Script de sauvegarde des images critiquesBACKUP_DIR="/path/to/backups/images/$(date +%Y%m%d)"mkdir -p "$BACKUP_DIR"# Liste des images critiques à sauvegarderCRITICAL_IMAGES=("database:prod" "api-gateway:stable" "authentication-service:1.5.2")for image in "${CRITICAL_IMAGES[@]}"; do echo "Sauvegarde de $image" docker save "$image" | gzip > "$BACKUP_DIR/$(echo $image | tr ':/' '-').tar.gz"done# Rotation des sauvegardes (conserver les 10 dernières)find /path/to/backups/images -maxdepth 1 -type d | sort -r | tail -n +11 | xargs -r rm -rf```. Ces sauvegardes permettent de restaurer rapidement un environnement fonctionnel même en cas de corruption du stockage Docker ou de suppression accidentelle d'images critiques.
Intégration avec les workflows DevOps et CI/CD
L'incorporation de `docker image ls` dans les pipelines CI/CD permet d'automatiser la validation et la gouvernance des images avant leur déploiement. Un pattern efficace consiste à vérifier systématiquement certaines propriétés des images nouvellement construites, comme leur taille, la présence de labels requis ou leur compatibilité avec les contraintes organisationnelles. Par exemple, un stage de validation dans un pipeline GitLab CI pourrait ressembler à : ```# .gitlab-ci.ymlvalidate_image: stage: validate script: - IMAGE_SIZE=$(docker image ls --format "{{.Size}}" $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA | sed 's/MB//') - if [ $IMAGE_SIZE -gt 500 ]; then echo "Image too large: $IMAGE_SIZE MB exceeds 500 MB limit" && exit 1; fi - LABELS=$(docker image inspect --format='{{.Config.Labels}}' $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA) - if [[ ! $LABELS =~ "maintainer" ]]; then echo "Missing required label: maintainer" && exit 1; fi - if [[ ! $LABELS =~ "version" ]]; then echo "Missing required label: version" && exit 1; fi - echo "Image validation successful"```. Ces contrôles automatisés garantissent que seules les images conformes aux standards définis progressent vers les environnements de production.
La mise en oeuvre d'un système de promotion d'images entre environnements constitue une pratique DevOps avancée qui améliore significativement la traçabilité et la fiabilité des déploiements. Cette approche, connue sous le nom de "promotion-based deployment", consiste à construire une image une seule fois, puis à la promouvoir à travers différents environnements après validation. Techniquement, cette promotion s'effectue via des opérations de tagging plutôt que de reconstruction : ```#!/bin/bash# Script de promotion d'image entre environnementsSOURCE_TAG="myapp:1.2.3-staging"TARGET_TAG="myapp:1.2.3-production"# Vérifier que l'image source existeif ! docker image ls $SOURCE_TAG --format "{{.Repository}}:{{.Tag}}" | grep -q "$SOURCE_TAG"; then echo "Error: Source image $SOURCE_TAG not found" exit 1fi# Appliquer un nouveau tag pour l'environnement cibledocker tag $SOURCE_TAG $TARGET_TAGecho "Image $SOURCE_TAG successfully promoted to $TARGET_TAG"```. Cette stratégie garantit que l'artefact testé et validé est exactement celui qui sera déployé en production, éliminant tout risque de variations entre environnements.
L'utilisation de registres intermédiaires ou de caches de pull-through optimise significativement les workflows CI/CD dans les architectures distribuées. Dans de tels environnements, un registry local peut être configuré comme proxy cachant et servant les images fréquemment utilisées, réduisant ainsi la dépendance aux registres externes et accélérant considérablement les builds et déploiements. Un script d'initialisation d'environnement peut exploiter `docker image ls` pour déterminer quelles images doivent être préchargées : ```#!/bin/bash# Script de préchauffage de cache registry pour nouvel environnementREGISTRY_CACHE="localhost:5000"REQUIRED_IMAGES=( "node:16-alpine" "postgres:13" "redis:6" "nginx:1.20")for img in "${REQUIRED_IMAGES[@]}"; do if ! docker image ls --format "{{.Repository}}:{{.Tag}}" | grep -q "$img"; then echo "Pulling and caching $img" docker pull $img docker tag $img $REGISTRY_CACHE/$img docker push $REGISTRY_CACHE/$img fidone```. Cette approche réduit considérablement les délais d'approvisionnement pour de nouveaux environnements ou noeuds de cluster.
Les politiques de rétention automatisées dans les pipelines CI/CD permettent de maintenir l'efficience du stockage tout au long du cycle de développement. Par exemple, un job de nettoyage périodique peut supprimer automatiquement les images de construction intermédiaires associées à des branches de feature fusionnées ou abandonnées : ```#!/bin/bash# Nettoyage des images de feature branches fusionnées# Récupérer les branches activesACTIVE_BRANCHES=$(git branch -r | grep -v HEAD | sed 's/origin\///' | tr '\n' '|' | sed 's/|$//')# Lister et filtrer les images de featuredocker image ls --format "{{.Repository}}:{{.Tag}}" | grep "feature-" | while read img; do # Extraire l'identifiant de feature de l'image (ex: feature-123 de myapp:feature-123-abcdef) FEATURE_ID=$(echo $img | grep -o 'feature-[0-9]\+') # Vérifier si la feature branch existe toujours if ! echo $ACTIVE_BRANCHES | grep -q "$FEATURE_ID"; then echo "Removing image for merged or deleted feature: $img" docker rmi $img fidone```. Cette gouvernance automatisée libère régulièrement des ressources sans intervention manuelle, optimisant le coût d'exploitation de l'infrastructure CI/CD.
L'intégration de la validation de conformité des images dans les workflows GitOps représente une approche moderne pour maintenir l'hygiène des déploiements. Dans ce paradigme, des contrôleurs automatisés peuvent régulièrement analyser l'inventaire des images déployées pour vérifier leur conformité avec les politiques organisationnelles ou réglementaires. Un rapport de conformité peut être généré via : ```#!/bin/bash# Génération de rapport de conformité des images déployéesecho "REPOSITORY,TAG,AGE_DAYS,VULNERABILITIES,COMPLIANT" > compliance_report.csv# Récupérer toutes les images déployées dans les différents environnementsDEPLOYED_IMAGES=$(kubectl get pods --all-namespaces -o jsonpath="{..image}" | tr -s '[[:space:]]' '\n' | sort | uniq)for img in $DEPLOYED_IMAGES; do # Vérifier si l'image est disponible localement if docker image ls $img --format "{{.Repository}}:{{.Tag}}" | grep -q "$img"; then AGE=$(docker image inspect $img --format "{{.Created}}" | xargs -I{} date -d {} +%s) AGE_DAYS=$(( ( $(date +%s) - $AGE ) / 86400 )) # Analyse de vulnérabilités (exemple avec trivy) VULNS=$(trivy image --severity HIGH,CRITICAL --quiet $img | grep -c CVE- || echo "0") # Déterminer la conformité selon les règles (exemple: max 30 jours, 0 vulnérabilités) if [ $AGE_DAYS -le 30 ] && [ $VULNS -eq 0 ]; then COMPLIANT="YES" else COMPLIANT="NO" fi echo "$img,$AGE_DAYS,$VULNS,$COMPLIANT" >> compliance_report.csv fidone```. Ce type d'intégration transforme le simple listing d'images en un outil stratégique de gouvernance des déploiements.