Architecture de référence¶

Ce chapitre décrit l'architecture de référence pour un déploiement Gitea en production, conçu pour la haute disponibilité et l'integration dans la zone Chaîne logicielle.

Vue d'ensemble¶

graph TD
    Users["Utilisateurs"] -->|HTTPS + SSH| LB
    subgraph Zone["Zone Chaine logicielle"]
        LB["Caddy / Nginx (LB)"] --> G1["Gitea Instance 1"]
        LB --> G2["Gitea Instance 2"]
        G1 --> PG["PostgreSQL<br/>(Primary/Replica)"]
        G1 --> Redis
        G1 --> S3["S3 / MinIO"]
        G2 --> PG
        G2 --> Redis
        G2 --> S3
    end

Composants¶

Gitea (application)¶

Le cœur du service. Chaque instance Gitea est stateless vis-à-vis du système de fichiers local : les dépôts Git peuvent etre stockes sur un volume partage ou sur le stockage objet (LFS).

PostgreSQL (base de données)¶

Stocke les metadonnees : utilisateurs, organisations, issues, pull requests, permissions, webhooks, audit log.

Redis (cache et sessions)¶

Gère le cache applicatif, les sessions utilisateur et la file d'attente des tâches asynchrones (mail, webhooks).

Stockage objet (S3 / MinIO)¶

Stocke les fichiers LFS, les avatars, les pieces jointes et les artefacts de packages. Decouple le stockage du système de fichiers local des instances Gitea.

Reverse proxy (Caddy / Nginx)¶

Termine TLS, distribue le trafic HTTP vers les instances Gitea, gère le passthrough SSH.

Flux réseau¶

SSH passthrough¶

Pour que les utilisateurs accedent aux dépôts via SSH (git@gitea.example.com:org/repo.git), le reverse proxy doit router le trafic SSH vers Gitea.

Option 1 : port dedie (recommande)¶

graph LR
    SSH["Port 22 (host)"] --> Gitea["Port 2222 (Gitea container)"]

Configuration Caddy (layer 4, si supporte) ou ssh sur le host qui redirige vers le conteneur.

Option 2 : SSH passthrough via le host¶

Créer un utilisateur git sur le host qui delegue au conteneur Gitea :

# /home/git/.ssh/authorized_keys
# Chaque cle publique est ajoutee automatiquement par Gitea

command="/usr/local/bin/gitea-shell",no-port-forwarding,no-agent-forwarding ssh-ed25519 AAAA...

Stockage des dépôts¶

Option A : volume partage (NFS / GlusterFS)¶

Les dépôts Git sont stockes sur un volume partage entre les instances Gitea. Simple mais introduit un SPOF réseau et des problèmes de verrouillage.

Option B : stockage local + réplication (recommande)¶

Chaque instance Gitea a son propre stockage local. Un mécanisme de réplication (Gitea mirroring ou rsync) maintient les dépôts synchronises. Le reverse proxy route les écritures vers l'instance primaire.

Ecriture (push) ──> Instance Gitea 1 (primaire) ──> replication ──> Instance Gitea 2
Lecture (clone)  ──> Instance Gitea 1 ou 2 (round-robin)

Guide de dimensionnement¶

Par taille d'équipe¶

Metriques a surveiller¶

Diagramme de déploiement (Podman)¶

  podman-compose.yml
  ┌─────────────────────────────────────────────┐
  │                                             │
  │  ┌────────┐  ┌────────┐  ┌────────┐        │
  │  │ caddy  │  │ gitea  │  │ gitea  │        │
  │  │ :443   │──│ :3000  │  │ :3000  │        │
  │  │ :22    │──│ :2222  │  │ :2222  │        │
  │  └────────┘  └───┬────┘  └───┬────┘        │
  │                  │           │              │
  │         ┌────────▼───────────▼──────┐       │
  │         │                           │       │
  │   ┌─────▼──┐  ┌───────┐  ┌────────┐│       │
  │   │postgres│  │ redis │  │ minio  ││       │
  │   │ :5432  │  │ :6379 │  │ :9000  ││       │
  │   └────────┘  └───────┘  └────────┘│       │
  │         │                           │       │
  │         └───────────────────────────┘       │
  │                                             │
  │  Volumes: gitea_data, postgres_data,        │
  │           redis_data, minio_data            │
  └─────────────────────────────────────────────┘