Logiciels & applications

Docker Hub : pull, push et dépôts privés, ce qu’il faut maîtriser avant de publier une image

Élise Prévost-Lemercier 6 min de lecture
Hub docker : pull, push, images privées

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.

Question 1 sur 6 Score : 0 / 6

Image, conteneur, Dockerfile, dépôt : qui fait quoi ?

Ces termes sont souvent mélangés. Le tableau suivant les remet à leur place.

TermeRôleLien avec les autres
DockerfileFichier d’instructions de constructionSa construction produit une image
ImageArtefact empaqueté, avec l’application et ses dépendancesSert de base à un conteneur
ConteneurInstance en cours d’exécution d’une imageCréé à partir d’une image
DépôtEspace regroupant les versions d’une même imageHébergé dans un registre
RegistreService de stockage et de distributionDocker 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é.

Schéma du cycle de vie d'une image sur le hub docker, du Dockerfile au conteneur
Schéma du cycle de vie d’une image sur le hub docker, du Dockerfile au conteneur

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èreDépôt publicDépôt privé
VisibilitéAccessible à tousRéservée aux utilisateurs autorisés
Usage typiqueLogiciel ouvert, contribution communautaireCode propriétaire, images internes
Contrôle d’accèsPeu pertinentCentral
Risque principalExposer par erreur un contenu sensibleGé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 ?
Élise Prévost-Lemercier

Partager cet article

Retour en haut