Docker Hub : pull, push et dépôts privés, ce qu’il faut maîtriser avant de publier une image
Docker Hub est le registre où l’on va chercher une image prête à l’emploi, et où l’on publie la sienne pour la partager avec une équipe ou avec tout le monde. On y stocke, on y gère et on y distribue des images de conteneurs. Cet article explique ce que le service fait réellement, comment s’y retrouver entre image, conteneur et Dockerfile, puis comment télécharger, publier et sécuriser ses images.
Docker Hub, un registre avant d’être un site web
Ce que le service stocke et distribue
Un registre est un service qui conserve des images et les met à disposition d’autres machines. Docker Hub remplit ce rôle : il centralise la découverte, le stockage, le partage et la distribution des images Docker. Le catalogue public met en avant des catégories, des images tendance et des images officielles, à côté d’images publiées par des organisations ou des particuliers. Parmi les noms connus figurent Ubuntu, Debian, Python, Nginx, PostgreSQL, MySQL, Redis ou Alpine Linux.
Testez vos connaissances sur Docker Hub
Répondez aux 6 questions, une à la fois, puis consultez votre score et les corrections.
Image, conteneur, Dockerfile, dépôt : qui fait quoi ?
Ces termes sont souvent mélangés. Le tableau suivant les remet à leur place.
| Terme | Rôle | Lien avec les autres |
|---|---|---|
| Dockerfile | Fichier d’instructions de construction | Sa construction produit une image |
| Image | Artefact empaqueté, avec l’application et ses dépendances | Sert de base à un conteneur |
| Conteneur | Instance en cours d’exécution d’une image | Créé à partir d’une image |
| Dépôt | Espace regroupant les versions d’une même image | Hébergé dans un registre |
| Registre | Service de stockage et de distribution | Docker Hub en est un exemple |
La chaîne se lit ainsi : le Dockerfile décrit, l’image fige, le registre conserve, le conteneur exécute. Empaqueter les dépendances dans l’image évite de configurer à la main chaque serveur.
Trouver et télécharger une image sans mauvaise surprise
Lire une fiche d’image avant de la télécharger
Les fiches affichent une description, des compteurs et un indicateur de fraîcheur, par exemple un âge en minutes, heures ou jours. Les ordres de grandeur sont parlants : l’image Python affiche 1B+ sur son premier compteur, comme nginx, alpine, postgres et mysql, tandis que neo4j affiche 100M+ et ai/qwen3 500K+. La définition exacte de ces compteurs n’est pas précisée sur la page, donc ils indiquent une popularité apparente, pas une garantie de qualité.

Avant de choisir, vérifiez dans l’ordre : le statut officiel ou l’éditeur, la date de dernière mise à jour, la version proposée et la compatibilité avec votre architecture. L’image Alpine, annoncée à 5 MB, illustre aussi l’intérêt de comparer les poids de plusieurs variantes.
Le geste du pull
Télécharger une image depuis un registre s’appelle un pull. L’image arrive sur votre machine, d’où vous lancez un conteneur. L’identifiant d’une image comprend un nom et un tag. Le tag désigne une variante ou une version. Fixer un tag précis plutôt que de laisser le choix par défaut rend vos environnements reproductibles : le développement, le test et la production tournent alors sur la même base.
Publier et maintenir sa propre image
De la construction au push
Le parcours est linéaire : écrire le Dockerfile, construire l’image, la taguer, puis l’envoyer vers le dépôt avec un push. Il faut au préalable un compte et une authentification auprès du registre. Un dépôt par application garde les versions groupées et lisibles pour ceux qui les consomment.
Mettre à jour sans casser ceux qui l’utilisent
Quand l’application évolue, on reconstruit une image actualisée et on la publie sous un nouveau tag. Les équipes qui consomment l’image peuvent ensuite choisir quand migrer. Une règle simple aide : ne jamais réécrire un tag déjà utilisé en production, car personne ne sait plus quelle version tourne où.
L’image comme trace d’un geste de fabrication
Une image laisse une empreinte de sa fabrication : chaque instruction du Dockerfile ajoute une couche, et l’ensemble garde la trace du système de base, des paquets installés et des fichiers copiés. Un tag renvoie donc à un état précis de cette chaîne, pas seulement à un numéro. Cela change la façon de choisir une image : une image de base légère laisse moins de traces à auditer, et un Dockerfile bien ordonné, avec les étapes stables en premier, rend les mises à jour plus lisibles. Lire une image comme un historique, et pas comme une boîte noire, aide à comprendre d’où viendrait une faille.
Dépôts publics ou privés : choisir son niveau d’ouverture
Le choix dépend de ce que l’on veut partager et avec qui. La page produit de Docker Hub annonce un nombre illimité de dépôts publics et propose aussi des dépôts privés avec contrôle d’accès. Les plafonds et conditions des dépôts privés ne sont pas détaillés ici : consultez l’offre en vigueur avant de vous engager.
| Critère | Dépôt public | Dépôt privé |
|---|---|---|
| Visibilité | Accessible à tous | Réservée aux utilisateurs autorisés |
| Usage typique | Logiciel ouvert, contribution communautaire | Code propriétaire, images internes |
| Contrôle d’accès | Peu pertinent | Central |
| Risque principal | Exposer par erreur un contenu sensible | Gérer correctement les droits |
Dans les deux cas, vérifiez ce que contient l’image avant de la pousser : un secret copié dans une couche reste présent dans l’historique, même si un dépôt est privé.
Sécurité des images et alternatives de registre
Juger la confiance qu’on accorde à une image
Une image reprise d’un tiers est du code que vous exécutez. Privilégiez les images officielles ou celles d’un éditeur identifié, regardez leur activité de maintenance et méfiez-vous des images anciennes ou sans documentation. Docker met aussi en avant des images de base durcies, présentées comme maintenues et assorties d’engagements de service. Surveillez les vulnérabilités publiées sous forme de CVE et mettez à jour régulièrement vos bases.
Quand envisager un autre registre
Docker Hub n’est pas le seul choix. Amazon ECR, par exemple, est un registre privé du cloud AWS, cité aussi pour sa recherche de vulnérabilités. Ces fonctions relèvent de ce service et ne doivent pas être attribuées d’office à Docker Hub. Un registre intégré à votre cloud devient pertinent si vos déploiements y sont déjà concentrés ou si votre politique de sécurité impose un registre privé sous votre contrôle.
Une courte checklist avant usage
- L’image est-elle officielle ou publiée par un éditeur connu ?
- Sa dernière mise à jour est-elle récente ?
- Le tag est-il précis et la version compatible avec votre architecture ?
- Le dépôt de destination est-il public ou privé, à dessein ?
- Avez-vous vérifié l’absence de secrets et de vulnérabilités connues ?
- Docker Hub : pull, push et dépôts privés, ce qu’il faut maîtriser avant de publier une image - 8 novembre 2026
- 5G, IoT et smart city : connecter la ville sans tout miser sur un seul réseau - 7 novembre 2026
- ESN et développement d’application web : choisir selon la complexité, pas l’étiquette - 6 novembre 2026



