Registres de conteneurs : comprendre le stockage et la distribution d'images

Vous avez construit une image Docker sur votre poste. Comment la déployer sur vos serveurs de production ? Comment garantir que toute l’équipe utilise exactement la même version ?

La réponse : une registry — un serveur qui stocke et distribue vos images, comme GitHub pour le code. Ce guide vous explique comment ça fonctionne et comment choisir la bonne registry (Docker Hub, Harbor, ECR…).

Ce que vous allez apprendre

• Ce qu’est une registry et le vocabulaire associé (repository, tag, digest)
• Comment les images sont stockées : le modèle manifest + layers
• Comment fonctionnent docker pull et docker push sous le capot
• Les différents types de registries : publiques, cloud, on-premise
• Les bonnes pratiques pour la production (sécurité, versionnement, scan)

Qu’est-ce qu’une registry d’images de conteneurs ?

Définition simple

Une registry (ou registre) est un serveur de stockage spécialisé qui :

• Stocke des images de conteneurs (comme un disque dur centralisé)
• Distribue ces images à qui en a besoin (comme un CDN)
• Versionne les images via des tags (comme Git avec les tags)

Analogie : si Docker Hub était une bibliothèque municipale, votre registry privée serait votre bibliothèque personnelle à la maison. Même système (des étagères avec des livres), mais contrôle total sur qui peut emprunter quoi.

Vocabulaire clé

Terme	Description	Exemple
Registry	Serveur qui héberge les images	Docker Hub, Harbor, AWS ECR
Repository	Espace logique contenant toutes les versions d’une même image (équivalent d’un dépôt Git)	nginx, mon-app, postgres
Tag	Étiquette qui identifie une version spécifique d’une image (comme un tag Git)	latest, v1.2.0, stable
Digest	Empreinte SHA256 unique et immuable de l’image (garantie d’intégrité)	sha256:a3b52c...

Glissez pour voir

Analogie bibliothèque :

• Registry = La bibliothèque (le bâtiment entier)
• Repository = Une étagère dédiée à un auteur (ex: tous les livres de Victor Hugo)
• Tag = Édition du livre (2024, édition collector, édition poche…)
• Digest = Code-barre ISBN unique (immuable, même si le titre change)

Image vs conteneur : la différence

• Image : paquet immobile (comme un .zip ou un exécutable), stocké dans la registry. C’est le “moule”.
• Conteneur : application en cours d’exécution, créée à partir de l’image. C’est “l’objet moulé” qui tourne.

Analogie : l’image est la recette de cuisine (fichier fixe), le conteneur est le plat cuisiné (processus vivant qui s’exécute).

Pourquoi on utilise une registry

Sans registry, vous devez déployer “à la main” : copier du code, installer des dépendances, gérer les versions manuellement sur chaque serveur. Cauchemar logistique dès que vous avez plus de 3 serveurs.

Les 4 bénéfices concrets

1. Reproductibilité garantie : même image partout (dev, staging, prod). Fini le “ça marche sur ma machine”.

2. Déploiements ultra-rapides : 1 build → N serveurs. Pull en quelques secondes grâce à la déduplication des layers.

3. Traçabilité : qui a publié quelle version, quand, avec quel tag. Audit trail complet.

4. Intégration CI/CD : votre pipeline build l’image, la pousse sur la registry, et Kubernetes/Nomad/Swarm la tire automatiquement. Zéro intervention manuelle.

Scénario réel : une équipe de 50 développeurs déploie 200 fois par jour. Sans registry, chaque développeur devrait copier manuellement les artefacts sur les serveurs. Avec une registry, le pipeline CI/CD fait tout automatiquement — gain de temps estimé : 8 heures de travail manuel par jour.

Pourquoi ça marche avec Docker/Podman/Kubernetes

Vous utilisez peut-être Docker, Podman, containerd, Kubernetes… Comment tous ces outils sont-ils compatibles ?

Les standards OCI (Open Container Initiative)

L’écosystème conteneurs s’appuie sur des standards ouverts définis par l’OCI (Open Container Initiative). L’idée : un format d’image et une API de distribution communs pour éviter le vendor lock-in à un outil spécifique.

Concrètement :

• Docker, Podman, containerd communiquent tous avec les registries via les mêmes endpoints HTTP /v2/...
• Vous pouvez changer de registry (passer de Docker Hub à Harbor) sans réécrire vos scripts
• Une image construite avec Docker fonctionne dans Kubernetes (qui utilise containerd sous le capot)

Analogie : c’est comme le format MP3 pour la musique. Peu importe que vous utilisiez iTunes, VLC ou Spotify — le fichier MP3 est lisible partout car c’est un standard ouvert.

Rappel express

L’OCI définit 3 standards clés :

• Image Spec : format de l’image (manifests, layers, configs)
• Runtime Spec : comment exécuter un conteneur
• Distribution Spec : API HTTP pour pousser/tirer des images (les fameux endpoints /v2/)

Plus d’infos : Open Container Initiative

Comment une image est stockée

Une image conteneur n’est pas un gros fichier monolithique. C’est un système en couches (layers) organisé par un manifest JSON.

Le modèle “manifest + layers”

Analogie : imaginez un livre (votre image).

• Le manifest = la table des matières (liste des chapitres + ordre)
• Les layers = les chapitres eux-mêmes (chaque instruction RUN, COPY dans le Dockerfile crée un layer)
• Le config blob = les métadonnées du livre (auteur, date, paramètres d’exécution comme CMD, ENV)

Chaque layer est identifié par un digest SHA256 (empreinte unique). Si deux images partagent le même layer (ex: Ubuntu de base), il n’est stocké qu’une seule fois. C’est la déduplication — ce qui rend le pull rapide.

Pourquoi ce système ?

1. Efficacité réseau : seuls les layers modifiés sont téléchargés
2. Économie d’espace : pas de duplication sur le serveur
3. Vérification d’intégrité : chaque layer a son SHA256, impossible de le falsifier sans changer l’empreinte

docker pull : comment ça marche

Quand vous tapez docker pull nginx:1.25, voici ce qui se passe en coulisses (en 5 étapes) :

1. Contact de la registry : Docker envoie GET /v2/library/nginx/manifests/1.25

2. Réception du manifest : la registry répond avec le JSON listant tous les layers (ex: 6 layers avec leurs SHA256)

3. Téléchargement des layers manquants : Docker compare avec ce qu’il a déjà localement. S’il a déjà 4 layers sur 6 (partagés avec une autre image), il ne télécharge que les 2 nouveaux.

4. Vérification des SHA256 : chaque layer est validé par son empreinte. Si un seul bit a changé, le SHA256 ne correspond plus → échec du pull.

5. Assemblage local : Docker empile les layers dans l’ordre et rend l’image prête à exécuter.

Timing réel : sur une connexion fibre, un docker pull d’une image de 500 Mo prend souvent 10-20 secondes grâce à la déduplication des layers (au lieu de 2-3 minutes si c’était un gros fichier unique).

docker push : envoyer une image vers la registry

Le processus inverse : vous avez construit une image localement (docker build) et voulez la partager.

1. Calcul des SHA256 : Docker calcule l’empreinte de chaque layer.

2. Vérification sur la registry : Docker fait des requêtes HEAD pour chaque layer. Si le SHA256 existe déjà, skip — pas de re-upload.

3. Upload des layers manquants uniquement : seuls les nouveaux layers sont envoyés via PUT /v2/.../blobs/uploads/.

4. Création du tag : Docker envoie le manifest final avec PUT /v2/.../manifests/v1.0, qui associe le tag au manifest.

Déduplication en action : si vous pushez une image basée sur Ubuntu (100 Mo), mais que la registry a déjà Ubuntu, vous n’envoyez que les 10 Mo de votre application. Gain de bande passante : 90%.

Authentification : comment sécuriser l’accès

Par défaut, une registry peut être publique (tout le monde peut pull) ou privée (authentification requise).

Le schéma Bearer Token (standard Docker Registry v2)

Quand vous tentez un docker pull sans authentification sur une registry privée :

1. Échec initial : la registry répond 401 Unauthorized avec un header WWW-Authenticate: Bearer realm="https://auth.registry.io/token"...

2. Demande de token : Docker contacte l’URL d’authentification avec vos credentials (login/password ou token)

3. Récupération du token JWT : le serveur d’auth renvoie un token JWT valide 30-60 minutes

4. Retry avec token : Docker refait la requête initiale avec Authorization: Bearer <token>

5. Succès : la registry valide le token et sert l’image

Pourquoi ce schéma ? Séparation entre authentification (gérer les users/password) et autorisation (vérifier si l’user peut pull/push). Permet d’intégrer LDAP, OAuth, OIDC facilement.

Nom d’une image : décryptage

Le format complet d’une image suit ce schéma :

[registry/][namespace/]repository[:tag|@digest]

Exemples concrets

Nom	Registry	Namespace	Repository	Tag/Digest
nginx	docker.io (implicite)	library (implicite)	nginx	latest (implicite)
nginx:1.25	docker.io	library	nginx	1.25
myorg/api:v2	docker.io	myorg	api	v2
harbor.example.com/prod/api:stable	harbor.example.com	prod	api	stable
nginx@sha256:a3b52c...	docker.io	library	nginx	Digest SHA256

Glissez pour voir

Pourquoi Docker Hub par défaut ? Pour simplifier. Quand vous tapez docker pull nginx, Docker ajoute automatiquement docker.io/library/nginx:latest.

Tags vs digests : la distinction critique

Pour référencer une image, vous pouvez utiliser soit un tag (ex: latest), soit un digest (ex: sha256:a3b52c...).

Tags (mutable)

• Flexibles : latest, stable, v1.2 peuvent pointer vers des images différentes au fil du temps
• Pratiques : faciles à retenir, à partager
• Risque : docker pull nginx:latest aujourd’hui ≠ docker pull nginx:latest demain

Digests (immuables)

• Garantie d’intégrité : sha256:a3b52c... pointe toujours vers la même image, bit pour bit
• Traçabilité : indispensable en production pour reproduire exactement un déploiement
• Moins lisibles : 64 caractères hexadécimaux

Bonnes pratiques

Attention

En production, toujours utiliser des digests ou des tags versionnés (ex: v1.2.3), jamais latest. Sinon, un redéploiement peut casser si latest a changé entre-temps.

Analogie : le tag est comme un lien court bit.ly (facile à partager mais peut pointer ailleurs demain), le digest est le lien permanent avec l’URL complète (toujours le même contenu).

Multi-architecture : une image, plusieurs plateformes

Certaines images (comme nginx, alpine) fonctionnent sur linux/amd64, linux/arm64, windows/amd64…

Comment ça marche ?

La registry stocke un manifest index (ou manifest list) qui pointe vers plusieurs manifests spécifiques à chaque plateforme.

Quand vous faites docker pull nginx, Docker détecte automatiquement votre OS et architecture, puis tire le bon manifest. Transparence totale — vous n’avez rien à faire.

Scénario réel : vous développez sur un Mac M1 (ARM64), vous déployez sur AWS EC2 (x86_64). Avec une image multi-arch, le même docker-compose.yml fonctionne partout sans modification.

Types de registries

Registries publiques

Pour qui : open source, prototypes, partage communautaire.

Registry	Caractéristiques	Limites
Docker Hub	100M+ images, gratuit pour public	Rate limiting (100 pulls/6h non-auth, 200 pulls/6h auth)
GitHub Container Registry (ghcr.io)	Gratuit, intégré GitHub Actions	Public par défaut, quotas sur stockage
Quay.io (Red Hat)	Scan vulnérabilités, build automatique	Payant pour privé

Glissez pour voir

Registries cloud managées

Pour qui : entreprises, scalabilité, intégration IAM.

Registry	Points forts	Prix indicatif
AWS ECR	Intégration IAM, scan vulnérabilités, haute dispo	$0.10/Go/mois stockage
Google Artifact Registry	Multi-format (Docker, Maven, npm…), analyse vulnérabilités	$0.10/Go/mois stockage
Azure Container Registry	Geo-réplication, intégration AKS, Content Trust	Dès $5/mois (Basic)

Glissez pour voir

Registries privées on-premise

Pour qui : souveraineté des données, conformité, air-gap.

Registry	Points forts	Complexité
Distribution (Docker Registry)	Open source officiel, simple	Basique, pas de GUI
Harbor	Enterprise-grade, GUI, RBAC, scan Trivy, réplication	Déploiement K8s recommandé
JFrog Artifactory	Multi-format, HA, LDAP/SAML	Payant, setup complexe
Sonatype Nexus	Multi-format, Maven-friendly	Java-centric

Glissez pour voir

Scénario de choix :

• Startup/prototype : Docker Hub gratuit
• CI/CD GitHub : GitHub Container Registry (zéro friction)
• Entreprise cloud AWS : ECR (IAM natif, pas de gestion d’infra)
• Banque/santé (conformité) : Harbor on-premise (contrôle total, audit)

Bonnes pratiques pour la production

1. Ne jamais stocker de secrets dans les images

Pourquoi : une fois dans l’image, le secret est visible par docker history ou en extrayant les layers.

Faire : utiliser des variables d’environnement, Kubernetes Secrets, HashiCorp Vault, AWS Secrets Manager…

# ❌ MAUVAIS
RUN echo "API_KEY=abc123" >> /app/.env

# ✅ BON
docker run -e API_KEY=abc123 mon-app

2. Versionner strictement les images

Pourquoi : traçabilité, rollback rapide, reproductibilité.

Faire :

• Tags sémantiques : v1.2.3, 2024-01-15-commit-abc123
• Jamais latest en production
• Stocker le digest dans votre manifeste K8s/Nomad

# ✅ BON (Kubernetes manifest)
spec:
  containers:
  - name: api
    image: harbor.example.com/prod/api@sha256:a3b52c...

3. Utiliser des tokens d’accès, pas de mots de passe

Pourquoi : révocation granulaire, rotation facile, moindre privilège.

Faire :

• Créer un token read-only pour les pulls CI/CD
• Token write-only pour les pushs CI/CD
• Rotation tous les 90 jours

# Exemple Docker Hub
docker login -u myuser --password-stdin < token.txt

4. Séparer les droits pull/push

Pourquoi : moindre privilège. La plupart des serveurs doivent juste pull, pas push.

Faire :

• Pipelines CI/CD : droits push
• Serveurs de prod : droits pull uniquement (ou anonymous pull si public)
• Développeurs : droits pull sur prod/*, push sur dev/*

Exemple Harbor :

Projet "prod" : Développeurs = Guest (pull only)
Projet "dev" : Développeurs = Developer (pull + push)

5. Scanner les images avant déploiement

Pourquoi : éviter de déployer des vulnérabilités connues.

Outils :

• Trivy (open source, rapide)
• Clair (intégré Harbor/Quay)
• Snyk, Aqua Security (payants, plus avancés)

Workflow recommandé :

# Pipeline CI/CD
- build image
- push to staging registry
- scan with Trivy
- if critical vulnerabilities → fail pipeline
- else → promote to prod registry

Dépannage : problèmes fréquents

Symptôme	Cause probable	Solution
401 Unauthorized	Token expiré ou absent	Re-login avec docker login
429 Too Many Requests	Rate limiting Docker Hub	Passer à un compte payant ou registry privée
manifest unknown	Tag inexistant ou typo	Vérifier le tag avec crane ls ou sur la GUI
Pull très lent	Layers non dédupliqués, registry loin	Utiliser une registry locale (Harbor) ou un proxy cache
x509 certificate errors	Certificat self-signed	Ajouter le CA au trust store ou --insecure-registry

Glissez pour voir

Que retenir ?

1. Une registry stocke et distribue vos images de manière centralisée, comme GitHub pour le code. Sans elle, pas de déploiement à grande échelle.

2. Les images sont organisées en layers (manifest + blobs) avec déduplication automatique. Résultat : pulls ultra-rapides et économie de bande passante.

3. Standards OCI : Docker, Podman, Kubernetes parlent tous le même langage HTTP /v2/. Vous pouvez changer de registry sans réécrire vos scripts.

4. Tags vs digests : les tags sont mutables (pratiques mais risqués), les digests sont immuables (obligatoires en production).

5. Bonnes pratiques : pas de secrets dans les images, versionnement strict, tokens au lieu de passwords, droits pull/push séparés, scan de vulnérabilités.

Testez vos connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

15 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Prochaines étapes

Utiliser la registry Docker Hub Prendre en main la registry Docker Hub

Quay.io : guide complet Prendre en main la registry Quay.io

×

📖 Voir la documentation →