4.1Registres : Hub, GHCR et registre privé
L'essentiel en 30 secondes
- Trois registres, trois usages : Docker Hub pour partager en public, GHCR lié au code pour la CI, registre privé (interne à l'entreprise) pour le sensible — le nom complet (registre/compte/image:tag) dit toujours d'où vient l'image.
- On s'authentifie avec un token à droits limités, jamais avec le mot de passe du compte : passé par --password-stdin, il ne traîne ni dans l'historique shell ni dans les logs CI — et se révoque en un clic en cas de doute.
- Réflexe d'Idir : en production, on tire un nom complet + tag immuable (jamais un raccourci ambigu), noté dans le compose de prod pour savoir quelle image tourne où.
Mini-cas filé — Idir publie l'image de sa startup sans fuiter le token
Idir, devops junior à Alger, doit publier l'image de l'application de sa startup pour que l'équipe la déploie : il choisit GHCR (le code est déjà sur GitHub), crée un token limité au push/pull, se connecte via --password-stdin et pousse un tag de version immuable. En production, l'équipe tire le nom complet et sait exactement quelle image tourne. Premier jalon du fil rouge : l'image est au bon endroit, accessible aux bonnes personnes, sans secret exposé.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h — et continue en 4.2, 4.3, 4.4 et 4.5.
1. Trois registres, trois usages
Docker Hub : la bibliothèque publique par défaut, pour partager (open source, images de base). GHCR (GitHub Container Registry) : le registre lié à votre code, parfait pour la CI — chaque dépôt y a ses paquets. Registre privé (interne à l'entreprise) : le coffre des images sensibles, à accès restreint. Le nom complet l'indique : registre/compte/image:tag — Idir lit d'un coup d'œil d'où vient chaque image.
Choisir, c'est trancher selon la sensibilité et l'usage : public pour l'open source, GHCR pour vos CI GitHub, privé pour l'interne sensible. Le compose de production fige le choix en notant les noms complets.
2. S'authentifier sans exposer
docker login avec un token à droits limités (push/pull), jamais le mot de passe du compte. Le token passe par --password-stdin (tube, pas d'argument visible) : rien dans l'historique shell, rien dans les logs. En CI, le token vit dans les secrets du dépôt, jamais dans le script ni dans le fichier de workflow.
Un token qui fuit se révoque en un clic : c'est pour cela qu'on ne partage jamais de compte — un compte partagé compromis, c'est tout l'accès à refaire. Comme Idir, on crée un token par usage et on révoque au moindre doute.
3. Tirer en production : figez la source
En production, on tire nom complet + tag immuable (une version figée), jamais un raccourci ambigu qui peut changer de contenu entre deux déploiements. La traçabilité « quelle image tourne où » commence par des noms complets notés dans le compose de prod.
Vérifier après le tirage : l'image démarrée correspond bien au tag voulu. Un tag mouvant en prod, c'est un déploiement qu'on ne peut ni reproduire ni auditer.
🔎 Exemple concret — 🔎 Exemple concret — Pousser vers GHCR
Le geste d'Idir : login sans trace, image traçable.
echo $GHCR_TOKEN | docker login ghcr.io -u moncompte --password-stdin
docker build -t ghcr.io/monequipe/app:1.2.0 .
docker push ghcr.io/monequipe/app:1.2.0
# en prod :
docker pull ghcr.io/monequipe/app:1.2.0Lecture : le token ne s'affiche jamais, l'image est traçable par son nom complet.
Leçon : --password-stdin évite le secret dans l'historique.
Vocabulaire de la section
- GHCR
- Le registre de GitHub, lié aux dépôts et à la CI : chaque projet y publie ses images.
Exemple simple : Idir y pousse l'image de l'application dont le code est déjà sur GitHub.
Ce que ce n'est pas : un simple dossier de stockage de fichiers.
Réflexe : code sur GitHub + image à publier en CI : penser GHCR.
- Token
- Jeton d'accès à droits LIMITÉS et révocable, qui remplace le mot de passe pour les usages automatisés.
Exemple simple : Idir crée un token push/pull au lieu de coller son mot de passe dans un script.
Ce que ce n'est pas : le mot de passe du compte, total et difficile à révoquer proprement.
Réflexe : automatiser un accès : créer un token limité, jamais le mot de passe.
- Nom complet
- Adresse sans ambiguïté d'une image : registre/compte/image:tag.
Exemple simple : L'équipe d'Idir déploie un nom complet avec version figée en production.
Ce que ce n'est pas : un raccourci ambigu qui peut changer de contenu.
Réflexe : production : toujours tirer un nom complet + tag immuable.
- --password-stdin
- Option de docker login qui lit le secret depuis un tube au lieu d'un argument visible.
Exemple simple : Idir pipe son token : rien ne reste dans l'historique shell.
Ce que ce n'est pas : l'option -p qui expose le secret en clair.
Réflexe : se connecter à un registre : toujours via stdin.
En pratique — En pratique — Publier au bon endroit
- Choisissez le registre adapté à votre cas (Hub/GHCR/privé).
- Créez un token à droits limités (push/pull).
- Connectez-vous via --password-stdin.
- Poussez un tag immuable et tirez-le ailleurs pour vérifier.
Script prêt à dire — expliquer le choix du registre à son responsable (30 s)
« C'est Idir : j'ai publié notre image sur GHCR avec un token limité au push et au pull, connecté sans laisser de trace. La production tire le nom complet avec la version figée, donc on sait exactement quelle image tourne. Si le token fuit, je le révoque en un clic. »
À dire quand on vous demande pourquoi ne pas « juste pousser en public » : montrez la sensibilité du code.
Modèle copier-coller — publier une version (GHCR)
echo $GHCR_TOKEN | docker login ghcr.io -u moncompte --password-stdin
docker build -t ghcr.io/monequipe/app:1.2.0 .
docker push ghcr.io/monequipe/app:1.2.0
docker pull ghcr.io/monequipe/app:1.2.0Image open source
Comme Idir mais vers Docker Hub en public : la communauté peut tirer librement, version figée pour la confiance.
Image interne sensible
Registre privé de l'entreprise, dépôt à accès restreint : seules les équipes habilitées tirent.
Token qui a fuité
Révoquer immédiatement le token, en créer un nouveau limité, vérifier les accès — sans toucher au compte.
Prod qui doit être auditable
Nom complet + tag immuable notés dans le compose de prod : on sait quelle image tourne où, à tout moment.
✓ Bonnes pratiques
- Tokens limités, jamais de mots de passe.
- Noms complets en production.
- Révoquer au moindre doute.
✗ Pièges fréquents
- Login avec -p et le secret visible (historique).
- Images internes poussées en public.
- Tags raccourcis ambigus en production.
Points clés à retenir
- Hub = public, GHCR = CI, privé = interne.
- Tokens limités via --password-stdin.
- Nom complet + tag immuable en production.
- On révoque sans hésiter.
Défi 48h — appliquez demain
Publiez une vraie image : créez un token limité, connectez-vous via --password-stdin, poussez un tag de version puis tirez-le depuis une autre machine.
- Je sais choisir le registre adapté (Hub, GHCR, privé).
- Je sais m'authentifier par token limité via --password-stdin.
- Je sais pousser et tirer un tag immuable traçable.
Questions fréquentes
Pourquoi --password-stdin plutôt que -p ?
Parce que -p expose le secret dans l'historique shell et les logs CI. Le pipe ne laisse aucune trace : le token transite sans jamais apparaître en clair.
Garder le même registre partout ?
Non : public pour l'open source, GHCR pour vos CI GitHub, privé pour l'interne sensible. Le compose de production fige le choix avec des noms complets.
En CI, comment s'authentifier au registre ?