Une agence qui gère plusieurs dizaines de sites conteneurisés finit par accumuler des images Docker construites à répétition : une image PHP-FPM avec les extensions nécessaires, une image Nginx avec la configuration adaptée, parfois une image WP-CLI outillée. Sans registre privé, chaque pipeline de déploiement reconstruit ces images depuis zéro, ou les pousse vers un registre public dont le quota gratuit se remplit vite avec quarante clients actifs.
Ce texte décrit l’architecture d’un registre de conteneurs privé mise en place pour centraliser ces images, les versionner correctement, et les rendre disponibles à tous les pipelines de l’agence sans dépendre d’un service tiers gratuit aux limites imprévisibles.
Pourquoi un registre public gratuit ne suffit plus
Docker Hub, dans son offre gratuite, impose des limites de débit sur les tirages d’images anonymes ou peu authentifiées, qui deviennent vite un problème quand plusieurs pipelines CI tirent la même image de base plusieurs fois par jour. GitHub Container Registry lève cette limite pour les dépôts publics, mais impose ses propres contraintes de gouvernance dès qu’il s’agit d’images contenant des éléments propriétaires à certains clients, comme des extensions premium préinstallées.
Le choix s’est porté sur Harbor, un registre open source auto-hébergeable, plutôt que sur un service géré, principalement pour garder le contrôle total sur la rétention des images et éviter une dépendance à un fournisseur supplémentaire dans la chaîne de déploiement.
Architecture retenue
┌─────────────────────────────────────────┐
│ VPS dédié (registre Harbor) │
│ │
│ ┌───────────┐ ┌───────────────────┐ │
│ │ Harbor │ │ Volume S3-compat │ │
│ │ (Core + │──▶│ (stockage blobs) │ │
│ │ Registry) │ └───────────────────┘ │
│ └─────┬──────┘ │
│ │ scan Trivy intégré │
└────────┼──────────────────────────────────┘
│ push / pull authentifiés (TLS)
┌─────┴──────┬──────────┬──────────┐
│ Pipeline │ Pipeline │ Pipeline │
│ Client A │ Client B │ Client C │
└────────────┴──────────┴──────────┘
Organiser les images par projet
Harbor structure ses images par « projets », équivalents à des espaces de noms. L’agence a retenu une convention à deux niveaux : un projet base pour les images génériques réutilisées par tous les clients, et un projet par client pour les images spécifiques qui en dérivent.
registre.agence.example/base/php-fpm-wordpress:8.2-3
registre.agence.example/base/nginx-wordpress:1.25-2
registre.agence.example/base/wp-cli-outillage:2.10-1
registre.agence.example/client-boutique-nord/php-fpm:2024-10-08
registre.agence.example/client-etude-avocat/php-fpm:2024-10-01
Les images de base suivent un versionnage sémantique lié à la version de PHP ou de Nginx qu’elles embarquent, suivi d’un numéro de révision interne incrémenté à chaque changement de configuration. Les images spécifiques à un client, elles, dérivent d’une image de base via un FROM et sont taguées par date de build, ce qui facilite l’audit a posteriori en cas d’incident.
Pousser une image depuis la CI
Chaque pipeline authentifie son push avec un compte de service à portée limitée à son propre projet Harbor, jamais avec les identifiants administrateur du registre :
- name: Connexion au registre
run: echo "${{ secrets.HARBOR_TOKEN }}" | docker login registre.agence.example \
-u "robot\$client-boutique-nord" --password-stdin
- name: Construire et pousser l'image
run: |
docker build -t registre.agence.example/client-boutique-nord/php-fpm:$(date +%Y-%m-%d) \
-f docker/php-fpm.Dockerfile .
docker push registre.agence.example/client-boutique-nord/php-fpm:$(date +%Y-%m-%d)
Le scan de vulnérabilités automatique
Harbor intègre nativement le scanner Trivy, déclenché automatiquement à chaque push d’image. Un rapport détaillé liste les paquets système obsolètes contenant des vulnérabilités connues, avec leur niveau de gravité. La politique de l’agence bloque la promotion d’une image vers un tag stable tant qu’une vulnérabilité critique n’est pas résolue, sans bloquer pour autant les tags de développement, pour ne pas ralentir le travail quotidien.
Rétention et nettoyage
Sans politique de rétention, le stockage du registre croît indéfiniment : chaque build quotidien laisse une nouvelle image. Une règle de rétention configurée dans Harbor conserve les dix dernières images par dépôt et supprime automatiquement les plus anciennes, sauf celles explicitement taguées stable ou production, protégées d’une suppression accidentelle.
Ce que ce registre a changé au quotidien
Avant sa mise en place, un déploiement typique reconstruisait l’image PHP-FPM depuis zéro à chaque exécution, téléchargeant les mêmes paquets système à chaque fois, pour un temps de build moyen d’environ quatre minutes. Avec les images de base pré-construites et mises en cache dans le registre, ce temps est tombé à moins d’une minute pour la majorité des déploiements, l’image spécifique au client se contentant d’ajouter quelques fichiers de configuration par-dessus une base déjà prête.
Un registre privé n’est pas un luxe réservé aux grandes équipes : dès qu’un même socle logiciel sert à plus de trois ou quatre projets, le temps gagné à ne plus le reconstruire dépasse vite le coût d’exploitation du registre.
En résumé
Centraliser les images Docker dans un registre privé a résolu deux problèmes distincts chez l’agence : la dépendance aux quotas d’un registre public gratuit, et la redondance des temps de build sur des images largement identiques d’un client à l’autre. La démarche de conteneurisation elle-même, celle qui consiste à écrire les premiers Dockerfile pour WordPress, reste un sujet séparé déjà traité en détail.
