Un docker private registry bien pensé sert à centraliser vos images, à verrouiller l’accès et à rendre vos déploiements beaucoup plus prévisibles. Dans un contexte DevOps, ce n’est pas juste un “stockage interne” : c’est un point de contrôle pour la qualité, la sécurité et la reproductibilité des releases.
Je vais aller au concret : à quoi il sert vraiment, comment choisir entre plusieurs options, comment publier et récupérer des images proprement, et surtout quels garde-fous mettre en place pour éviter les mauvaises surprises en production.
Les points à retenir avant de mettre en place un registre privé Docker
- Un registre privé sert à stocker des images en interne avec un contrôle fin des accès, des versions et de la traçabilité.
- Le choix n’est pas binaire : un registre minimal, Harbor ou un service managé n’impliquent pas le même niveau d’exploitation ni les mêmes fonctions de sécurité.
- Le flux standard reste simple : authentification, tag clair, push, puis pull côté CI/CD ou Kubernetes.
- En production, je privilégie toujours HTTPS, le contrôle d’accès par rôle, l’analyse de vulnérabilités et des tags immuables ou des digests.
- Les erreurs les plus coûteuses viennent souvent du nommage, de la rétention et de l’absence de nettoyage des blobs inutilisés.
Pourquoi un registre privé change la gestion des images
Un registre privé devient utile dès que vos images ne sont plus de simples artefacts temporaires. Dès que plusieurs équipes construisent, testent et déploient les mêmes services, il faut un point unique pour retrouver la bonne version, contrôler qui peut la consommer et éviter que des images “fantômes” circulent dans des environnements différents.
Je considère aussi ce sujet comme une vraie brique de sécurité. Une image Docker contient souvent bien plus qu’un binaire : dépendances, configuration, variables d’environnement, parfois des clients internes ou des certificats. Les laisser traîner dans un registre public ou mal gouverné est rarement une bonne idée.
Le bénéfice le plus visible, au quotidien, c’est la reproductibilité. Si vous déployez une image taguée de façon rigoureuse, vous savez exactement ce qui tourne en préproduction et en production. Et si vous poussez plus loin, en pinant les déploiements sur un digest plutôt que sur un tag mutable, vous supprimez une bonne partie des ambiguïtés liées aux versions.
Je vois souvent cette règle simple fonctionner : le registre privé sert à la fois de bibliothèque d’artefacts, de contrat de livraison entre CI et runtime, et de zone de confiance pour les équipes. C’est ce trio qui le rend vraiment indispensable dès qu’on dépasse le cadre du projet isolé. Reste maintenant à choisir la forme la plus adaptée à votre équipe.
Comment choisir entre un registre simple, Harbor et un service managé
Le bon choix dépend surtout de votre niveau d’exploitation accepté, de vos besoins de sécurité et de votre contexte d’hébergement. Si vous voulez juste un dépôt interne rapide à mettre en place, la distribution officielle Docker suffit souvent. Si vous avez besoin d’interface, de rôles, de scans et de réplication, Harbor devient très vite plus confortable. Si votre priorité est de réduire l’administration, un service managé prend l’avantage.
| Option | Forces | Limites | Je la choisis quand |
|---|---|---|---|
| Registre minimal basé sur Docker Distribution | Très léger, simple, bon contrôle, peu de composants | Peu de fonctions natives autour des rôles, de l’interface et du scan | Je veux un dépôt interne sobre pour une équipe réduite ou un lab sérieux |
| Harbor | RBAC, analyse de vulnérabilités, signature, réplication, interface web | Plus de pièces à opérer et à maintenir | Je veux une vraie plateforme d’images avec gouvernance et conformité |
| Service managé cloud | Moins d’exploitation, intégration IAM, haute disponibilité plus simple à obtenir | Coût variable selon stockage et trafic, moins de contrôle sur la pile | Je privilégie la rapidité d’exécution et je veux éviter d’administrer l’infra |
Dans une équipe DevOps qui travaille en France ou avec des contraintes de résidence des données, je regarde aussi où sont stockées les images et quelles latences cela ajoute aux pipelines. Quand les builds sont fréquents, un registre trop éloigné finit par coûter du temps, donc indirectement de l’argent.
La règle pratique que j’applique est simple : registre minimal si le besoin est surtout fonctionnel, Harbor si la sécurité et la gouvernance montent en importance, service managé si l’équipe veut acheter du temps d’exploitation. Cette décision étant posée, le flux de publication reste étonnamment compact.
Le flux minimal pour publier et récupérer une image sans friction
La séquence standard est courte, et c’est une bonne chose : plus elle est lisible, plus elle est facile à automatiser dans une chaîne CI/CD. La documentation Docker rappelle d’ailleurs que l’on pousse et récupère des images vers un registre distant en le nommant explicitement, avec un port si besoin, et que les identifiants sont gérés par docker login.
Dans la pratique, le flux ressemble à ceci :
docker login registry.exemple.fr
docker tag mon-api:1.4.2 registry.exemple.fr/backend/mon-api:1.4.2
docker push registry.exemple.fr/backend/mon-api:1.4.2
docker pull registry.exemple.fr/backend/mon-api:1.4.2Le point sensible ici n’est pas la commande elle-même, mais le nommage. J’aime des tags explicites, construits à partir d’un numéro de version, d’un SHA Git ou d’un couple version + environnement. En revanche, je déconseille fortement de déployer en production un simple latest si vous tenez à la traçabilité.
Si vous exposez un registre local, le port 5000 est un repère courant, y compris dans la documentation Docker. C’est pratique en environnement interne, mais cela ne dispense pas d’un vrai certificat TLS et d’une authentification robuste dès que le registre sort du réseau de test.
Un autre détail utile : lors d’un push, le démon Docker envoie par défaut jusqu’à cinq couches en parallèle. Sur une liaison lente, cela peut créer des timeouts. Je réduis alors la concurrence côté démon au lieu de bricoler le pipeline, parce que le problème est souvent réseau avant d’être applicatif.
Une fois ce flux en place, la vraie question devient la suivante : comment s’assurer que les bonnes personnes accèdent aux bonnes images, sans exposer le dépôt à des dérives de sécurité ?
Les règles de sécurité qui comptent vraiment
Sur ce sujet, je préfère la sobriété efficace aux empilements théoriques. Le premier niveau de protection reste le transport chiffré : Docker utilise HTTPS par défaut pour parler à un registre, sauf cas particulier explicitement autorisé en mode non sécurisé. En production, je traite cette exception comme un signal d’alerte, pas comme une option normale.
Ensuite vient le contrôle d’accès. Un registre privé digne de ce nom doit distinguer au minimum les droits de lecture, d’écriture et d’administration. L’authentification par jeton, avec challenge HTTP et Bearer token, est le mécanisme attendu sur l’écosystème Docker moderne. Ce n’est pas un gadget : c’est ce qui permet de séparer proprement les autorisations par équipe, projet ou environnement.
| Mesure | Ce qu’elle protège | Ce que je recommande |
|---|---|---|
| TLS | Interception, altération en transit, erreurs de confiance | Certificat valide, idéalement signé par une CA interne ou reconnue |
| RBAC | Accès trop larges aux images et aux projets | Droits minimums par équipe, par dépôt ou par projet |
| Scan de vulnérabilités | Images contenant des paquets connus comme vulnérables | Scan à l’envoi et blocage des images critiques avant mise en prod |
| Signature | Images falsifiées ou non approuvées | Signer les images livrées, surtout pour les releases stables |
| Rétention et garbage collection | Explosion du stockage par accumulation de couches inutiles | Politique de conservation claire et nettoyage régulier des blobs orphelins |
Harbor se distingue précisément parce qu’il rassemble plusieurs de ces briques dans une même plateforme : politiques, contrôle d’accès, analyse, signature et réplication. Je le recommande souvent quand la maturité sécurité devient un sujet à part entière, pas seulement un ajout tardif dans le pipeline.
À l’inverse, si vous n’avez pas encore de politique de publication stable, la meilleure décision n’est pas d’empiler les outils, mais de fixer quelques règles simples. Un registre proprement sécurisé vaut mieux qu’une usine à gaz difficile à maintenir. C’est aussi ce qui évite les erreurs de base, et elles sont plus fréquentes qu’on ne l’imagine.
Les erreurs que je vois le plus souvent en production
La première erreur consiste à utiliser un registre interne sans certificat fiable, sous prétexte qu’il est “réservé au réseau privé”. En pratique, cela finit souvent par casser des pipelines, compliquer le débogage et encourager des contournements locaux. Un registre privé doit être aussi propre qu’un service exposé, sinon il devient une zone grise que personne n’ose toucher.
La deuxième erreur est de confondre tag et identité. Un tag est utile pour lire une version, mais il reste mutable. Si vous voulez figer une livraison, utilisez un digest ou une convention de tags qui ne réécrit jamais la même référence. C’est un point simple, mais c’est souvent là que les équipes perdent la traçabilité.
La troisième erreur est la négligence du cycle de vie des images. Les couches inutilisées s’accumulent vite, surtout si vos pipelines génèrent beaucoup de tags intermédiaires. Sans rétention, sans nettoyage et sans supervision du stockage, le registre grossit silencieusement jusqu’au jour où il ralentit, ou sature.
Je vois aussi des équipes oublier l’impact du réseau. Docker pousse plusieurs couches en parallèle par défaut, et cela passe très bien sur un LAN correct. Sur une liaison plus faible ou un VPN instable, le volume de trafic concurrent peut créer des échecs intermittents qui ressemblent à des bugs applicatifs alors qu’il s’agit simplement d’un réglage de transport.
Dernier piège classique : ne pas prévoir la récupération après incident. Un registre n’est pas seulement un lieu d’écriture, c’est un composant de livraison. Si vous ne testez pas la restauration, la réplication ou le basculement, vous ne savez pas vraiment comment votre chaîne se comporte le jour où le stockage ou le nœud principal tombe. Une fois ces pièges identifiés, il reste à décider du niveau de sophistication qui correspond réellement à votre organisation.
Le niveau de maturité que je recommande selon l’équipe
Pour une petite équipe, je conseille souvent un registre minimal bien durci : TLS, authentification, sauvegardes, politique de rétention et conventions de nommage claires. C’est suffisant pour obtenir de la fiabilité sans transformer l’outil en projet parallèle.
Pour une équipe qui partage beaucoup d’images entre services, Harbor devient souvent le meilleur compromis. Il apporte une vraie lecture opérationnelle du dépôt, notamment grâce aux rôles, à l’interface et aux contrôles de sécurité intégrés. Je le considère comme un bon choix dès que plusieurs développeurs, plusieurs pipelines et plusieurs environnements consomment le même catalogue d’images.
Pour une organisation distribuée, avec plusieurs sites ou une forte contrainte d’exploitation, un service managé peut être plus rationnel. On paie alors surtout la simplicité opérationnelle et l’intégration, plutôt que la maîtrise complète de la pile. Ce n’est pas toujours le choix le moins cher, mais c’est souvent le plus efficace quand le temps d’équipe est limité.
Si je devais résumer ma position, je dirais ceci : gardez le registre aussi simple que possible, mais pas plus simple que ce que vos exigences de sécurité et de gouvernance imposent. Un dépôt d’images n’est pas un détail d’infrastructure. C’est un point d’ancrage de votre chaîne DevOps, et quand il est propre, tout le reste devient plus lisible.
