Architecture de référence Harbor¶

Vue d'ensemble des composants¶

Harbor est compose de plusieurs services qui s'appuient sur un registre OCI (Distribution) en backend.

graph TD
    LB["Load Balancer<br/>(Traefik / Nginx)"] -->|:443| Core["Harbor Core<br/>(API, UI, Auth)"]
    Core --> Registry["Registry<br/>(Distribution)"]
    Core --> Jobs["Job Service<br/>(GC, Replic.)"]
    Core --> Trivy["Trivy Adapter<br/>(Scan vuln.)"]
    Registry --> S3["Object Store<br/>(S3/MinIO)"]
    Jobs --> PG["PostgreSQL<br/>(metadata)"]
    PG --> Redis["Redis<br/>(cache/queue)"]

Detail des composants¶

Harbor Core¶

Le composant central qui expose l'API REST et l'interface web.

Registry (Distribution)¶

Le registre OCI sous-jacent qui stocke les blobs (layers) et les manifests.

• Reçoit les push/pull via l'API Docker Registry v2 / OCI Distribution
• Stocke les blobs dans le backend de stockage configure (filesystem, S3, MinIO)
• Harbor Core intercepte les requêtes pour appliquer l'authentification et le RBAC

Trivy Adapter¶

Scanner de vulnerabilites integre qui analyse les images apres chaque push.

graph LR
    Push["Image poussee"] --> Core["Harbor Core"] --> Trivy["Trivy Adapter"] --> CVE["Base CVE<br/>(NVD, GitHub Advisory)"]
    Trivy --> Rapport["Rapport CVE<br/>stocke dans PostgreSQL"]
    Rapport --> Policy["Politique :<br/>bloquer si Critical/High"]

Job Service¶

Service de tâches asynchrones :

• Garbage collection : nettoyage des blobs orphelins
• Réplication : synchronisation vers/depuis d'autres registres
• Scan : orchestration des scans de vulnerabilites en lot
• Retention : application des regles de retention des tags

Redis¶

Cache et file de messages :

• Cache des sessions utilisateur et des tokens
• File d'attente pour les jobs asynchrones (scan, réplication, GC)
• Cache des résultats de scan recents

PostgreSQL¶

Base de données relationnelle stockant toutes les metadonnees :

Object Storage (S3/MinIO)¶

Stockage des blobs (layers d'images, charts Helm, artefacts OCI).

Modèle de projets¶

Harbor organise les artefacts en projets. Chaque projet est un namespace isole avec son propre RBAC, ses quotas et ses politiques.

Structure recommandee¶

harbor.example.com/
├── library/              # Images de base validees (public interne)
│   ├── debian:bookworm-slim
│   ├── python:3.12-slim
│   └── node:22-alpine
├── infra/                # Images d'infrastructure
│   ├── traefik:v3.1
│   ├── postgres:16
│   └── redis:7
├── app-frontend/         # Application frontend (equipe frontend)
│   ├── webapp:v2.1.0
│   └── webapp:sha-a1b2c3d
├── app-backend/          # Application backend (equipe backend)
│   ├── api:v3.0.1
│   └── worker:v3.0.1
├── charts/               # Charts Helm
│   ├── webapp-chart:1.0.0
│   └── api-chart:2.1.0
└── mirror/               # Miroir d'images publiques
    ├── docker.io/library/nginx:1.27
    └── quay.io/prometheus/prometheus:v2.53

Configuration de projet¶

Robot accounts¶

Les robot accounts remplacent les credentials humains pour l'automatisation (CI/CD, Kubernetes).

Types de robots¶

Creation d'un robot account¶

# Via l'API Harbor
curl -X POST https://harbor.example.com/api/v2.0/robots \
  -H "Content-Type: application/json" \
  -u admin:Harbor12345 \
  -d '{
    "name": "robot-ci-push",
    "description": "CI/CD push for app-backend",
    "duration": -1,
    "level": "project",
    "permissions": [
      {
        "namespace": "app-backend",
        "kind": "project",
        "access": [
          {"resource": "repository", "action": "push"},
          {"resource": "repository", "action": "pull"},
          {"resource": "tag", "action": "create"}
        ]
      }
    ]
  }'

Regles de réplication¶

Configuration type¶

Topologie de réplication¶

graph TD
    Internet["Internet<br/>Docker Hub, Quay.io"] -->|Pull planifie| Principal["Harbor principal<br/>harbor.example.com"]
    Principal -->|Push chaque push| DR["Harbor DR<br/>(passif)"]
    Principal -->|Push chaque push<br/>label=edge| Edge["Harbor Edge<br/>(air-gapped)"]

Guide de sizing¶

Dimensionnement par profil¶

Facteurs de croissance¶

Le stockage croit en fonction de :

• Nombre de builds CI/CD par jour : chaque push ajoute des layers
• Taille des images : images Go (~50 Mo) vs images Java (~300 Mo) vs images ML (~2 Go)
• Retention des tags : combien de versions sont conservees
• Deduplication : les layers partages entre images sont stockes une seule fois

Stockage = Nb_images × Taille_moyenne × (1 - Taux_dedup) × Nb_versions_retenues

Haute disponibilité¶

Pour un déploiement HA :