Comparaison des solutions de registre¶

Cette page alimente un ADR (Architecture Decision Record) pour le choix du registre d'artefacts interne. Pour le format ADR, voir Documenter les decisions d'architecture.

Grille de comparaison¶

Analyse détaillée¶

Harbor — Recommande pour registre d'entreprise¶

Forces :

• Scan de vulnerabilites integre avec Trivy (configurable : bloquer les images critiques)
• Réplication multi-registre avancee avec filtres granulaires (nom, tag, label)
• RBAC complet avec projets, rôles (admin, developer, guest) et robot accounts
• Signature d'images native (Cosign et Notation)
• Tag immutability pour empecher l'ecrasement de versions en production
• Garbage collection en ligne sans interruption de service
• Gestion de quotas par projet (stockage et nombre d'artefacts)
• Projet gradue CNCF, communauté active, mises a jour régulières
• Support complet OCI : images, charts Helm, SBOM, attestations

Faiblesses :

• Stack complexe (Core, Registry, Trivy, Redis, PostgreSQL, Job Service)
• Empreinte mémoire plus elevee (~2 Go pour la stack complète)
• Configuration initiale plus longue qu'un registre simple
• Pas de gestion de packages generiques (npm, Maven, pip — utiliser Gitea Packages pour cela)

Verdict : choix par defaut pour une DSI qui a besoin d'un registre securise avec scan, signature, réplication et RBAC.

Gitea Packages — Si Gitea est déjà en place¶

Forces :

• Zero installation supplémentaire si Gitea est déjà déployé comme SCM
• Supporte de multiples types de packages (npm, Maven, PyPI, NuGet, OCI, Helm)
• Leger, integre dans le workflow Gitea
• Permissions alignees sur les repositories Gitea
• API compatible OCI pour les images conteneur

Faiblesses :

• Pas de scan de vulnerabilites integre
• Pas de réplication inter-registres
• Pas de robot accounts dédiés (utilise les tokens Gitea)
• Pas de gestion de quotas
• Pas de tag immutability
• Fonctionnalités registre limitees comparées a un registre dedie

Verdict : acceptable pour les équipes qui ont des besoins simples et utilisent déjà Gitea. Ne remplace pas un registre dedie pour les exigences de sécurité d'entreprise.

GitLab Container Registry — Lie a l'ecosysteme GitLab¶

Forces :

• Integration profonde avec GitLab CI/CD
• Scan de vulnerabilites integre (edition Enterprise)
• Geo-réplication (edition Enterprise)
• Gestion mature, large communauté

Faiblesses :

• Les fonctionnalités avancees (scan, quotas, geo-réplication) sont réservées a l'edition Enterprise payante
• Lie a l'ecosysteme GitLab (peu pertinent si le SCM est Gitea)
• Pas de support Helm charts en natif
• Empreinte tres elevee (GitLab complet ~4 Go RAM minimum)
• Pas de tag immutability native

Verdict : pertinent uniquement si GitLab est déjà le SCM et le CI/CD de l'organisation. Non retenu dans notre contexte Gitea.

Docker Distribution — Minimaliste¶

Forces :

• Ultra-leger (~128 Mo RAM)
• Simple a déployer (un seul binaire Go)
• Base de nombreux registres (Harbor l'utilise en backend)
• API OCI/Docker Registry v2 de référence

Faiblesses :

• Aucune UI
• Aucun RBAC natif (proxy auth externe requis)
• Aucun scan de vulnerabilites
• Aucune réplication avancee (miroir lecture seule uniquement)
• Garbage collection hors ligne (arrêt du registre requis)
• Aucun audit log
• Aucune gestion de quotas

Verdict : brique de base, pas un produit fini. Acceptable pour un lab ou un cache local, pas pour un usage d'entreprise.

Matrice de decision¶

graph TD
    A{Besoin scan + signature ?} -->|Oui| B[Harbor]
    A -->|Non| C{Gitea deja en place ?}
    C -->|Oui| D{Besoins simples ?}
    C -->|Non| E{GitLab en place ?}
    D -->|Oui| F[Gitea Packages]
    D -->|Non| B
    E -->|Oui, Enterprise| G[GitLab CR]
    E -->|Non| H{Budget minimal ?}
    H -->|Oui| I[Docker Distribution]
    H -->|Non| B

Decision recommandee¶

Pour une DSI avec des exigences de sécurité (scan, signature, réplication, RBAC, audit) :

Critères de reevaluation¶

Cette decision doit etre reevaluee si :

• Gitea Packages integre le scan de vulnerabilites et la réplication
• Un changement de SCM vers GitLab rend le GitLab CR plus pertinent
• Les besoins en registre se limitent a un usage lab/dev sans exigence de sécurité
• Harbor change de modèle de licence ou de gouvernance CNCF
• Une solution alternative (Zot, par exemple) atteint la maturité et la couverture fonctionnelle de Harbor