Maximize Page
Tech & DevOps HubEspace Tech & DevOps: Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussions Explore the world of development, the cloud and DevOps tools

Choisir la bonne image (Docker Hub)

Date de l'article:30-10-2025
Docker
Choisir la bonne image Docker est crucial pour la sécurité, la stabilité et la performance des projets. Voici une méthode complète et structurée pour bien faire son choix.

Pour choisir la bonne image Docker, vérifiez qu'elle est officielle et fiable, choisissez une image légère (comme slim ou alpine) pour réduire la taille, et utilisez un tag avec une version spécifique pour plus de stabilité. Vous pouvez aussi utiliser les outils de recherche de Docker Hub pour filtrer et explorer les images

1. Définir son besoin
Identifier clairement le contexte évite de perdre du temps et d'embarquer des dépendances inutiles
Quel service ? Java, PostgreSQL, Nginx…
Pour quel usage ? build, runtime, CI/CD
Quel OS ? debian, alpine…
Production ou dev ?
Exemple :
eclipse-temurin:17-jre-alpine (runtime)
plutôt que eclipse-temurin:17-jdk (build)
2. Vérifier la source

Sur Docker Hub, toutes les images ne se valent pas. Il faut repérer celles qui sont officielles ou maintenues par l'éditeur

Official Image Exemples : postgres nginx ubuntu openjdk

Verified Publisher → maintenues par une entreprise fiable

Évitez les images inconnues ou non maintenues
3. Vérifier l'activité

Une image non maintenue est une image vulnérable.
Même une image officielle peut devenir un risque si elle n'est plus maintenue.

Vérifier :
La date de la dernière publication sur Docker Hub.
La fréquence des mises à jour (patchs de sécurité, nouvelles versions)
La disponibilité du Dockerfile source sur GitHub (lié dans la description)
Le nombre de pulls et d'étoiles — indicateurs de popularité et d'adoption
Exemple: postgres:16 → maintenu activement
4. Scanner les vulnérabilités
Ne déployez jamais une image sans vérification CVE
Vérifier avec les commandes:
# Docker Scout (intégré à Docker Desktop / CLI)
docker scout quickview postgres:16-alpine

# Trivy — scanner open source très complet
trivy image postgres:16-alpine

# Trivy avec sortie filtrée (CRITICAL + HIGH uniquement)
trivy image --severity CRITICAL,HIGH postgres:16-alpine
Référence : docs.docker.com — docker scout quickview
Intègrez "Trivy" ou "Docker Scout" dans les pipelines GitHub Actions/GitLab pour bloquer les images avec des CVE critiques avant le déploiement
5. Choisir le bon tag
Ne jamais utiliser latest en production.

Un docker pull ultérieur peut ramener une version totalement différente, au risque de casser "silencieusement" l'application

à éviter
FROM openjdk:latest
FROM postgres:latest
Recommandé - version fixe
FROM eclipse-temurin:17-jre-alpine
FROM postgres:16.3-alpine
FROM jenkins/jenkins:lts-jdk17
FROM node:22-alpine
Utiliser SHA256 pour la reproductibilité
6. Comparer les variantes
:alpine
Ultra légère
Taille minimale,
surface d'attaque réduite

Certaines libs manquent et la compilation est parfois complexe
:slim
Bon compromis
Stable, compatible glibc,
bonne taille

Un peu plus lourde qu'alpine

:(full)
Complète
Pas de problème de compatibilité
Volumineuse (300 Mo+)
surface d'attaque maximale
:jre / :fpm
Runtime uniquement
Taille optimale pour la prod
Ne peut pas compiler
est réservé au déploiement final
7. Lire les instructions d'utilisation
Les pages officielles indiquent souvent :
  • Les variables d'environnement
  • Les ports exposés
  • Les volumes
  • les commandes par défaut (CMD ou ENTRYPOINT)

Exemple concret : PostgreSQL
Sur Docker Hub: https://hub.docker.com/_/postgres

Et en production (Distroless)
gcr.io/distroless/java17-debian13:nonroot
Pas de shell
Surface minimale
Sécurité maximale
Toujours utiliser :nonroot

Multi-stage build
Exemple de Dockerfile avec image finale minimale
FROM maven:3.9-eclipse-temurin-17 AS build
RUN mvn package

FROM gcr.io/distroless/java17-debian13:nonroot
COPY --from=build app.jar app.jar
Sécurité runtime
(distrolles)
non-root
ports >1024
read-only FS
scan sécurité
Debug & observabilité
Distroless = pas de debug système
Spring Boot Actuator
Logs centralisés
Prometheus / Grafana

Tableau de décision rapide
Besoin Choix Raison
Image légère alpine taille minimale
Compatibilité slim glibc
Production sécurisée distroless surface minimale
Build maven / node SDK inclus
Reproductibilité sha256 immuable

Laissez-moi un commentaire

En postant un commentaire anonyme, vous adhérez automatiquement aux conditions d'utilisation du site.