Comprendre les modèles de déploiement de gitrust¶

Ce que vous allez comprendre¶

• Comparer les trois topologies de déploiement (dev local, mono-machine prod, haute disponibilité) et leurs compromis
• Identifier les limites de la mise à l'échelle horizontale de gitrust dans sa version actuelle
• Évaluer quelle topologie correspond à votre contexte (taille d'équipe, contraintes de disponibilité, budget)

Le problème concret¶

Vous hébergez gitrust pour une équipe de 8 développeurs. Tout fonctionne bien, mais vous vous posez la question : faut-il un deuxième serveur pour la résilience ? Peut-on mettre gitrust derrière un load balancer ? Que se passe-t-il si le disque dur tombe ?

L'analogie¶

Les trois topologies ressemblent aux trois tailles de cuisine dans un restaurant : - Cuisine de maison (dev local) : tout sur le même plan de travail, pratique, pas question d'accueillir 50 couverts - Cuisine de restaurant (mono-machine prod) : séparation des postes, robuste, suffisant pour 20-50 couverts - Cuisine industrielle (HA) : plusieurs cuisines qui travaillent en parallèle, mais la coordination est un métier à part entière

La plupart des équipes de 3-20 personnes n'ont besoin que de la cuisine de restaurant.

Le modèle¶

Topologie 1 — Développement local¶

graph LR
    subgraph "Machine du développeur"
        G[gitrust :4000 + :2222]
        PG[(PostgreSQL :5432)]
        FS[./data/repos]
    end
    DEV[Navigateur / git] --> G
    G --> PG
    G --> FS

Caractéristiques : - Tout sur la même machine, tout en localhost - APP_DEBUG=true, COOKIE_SECURE=false, RUST_LOG=debug - PostgreSQL lancé via docker compose up -d dans database/ - Pas de reverse-proxy, pas de TLS - SESSION_BACKEND=memory acceptable (données perdues au redémarrage)

Usage : test de fonctionnalités, développement de plugins, démonstrations offline.

Topologie 2 — Mono-machine production (recommandée)¶

graph LR
    subgraph "Internet"
        CLI[Navigateur / git client]
    end

    subgraph "Serveur unique"
        NGX[Nginx :443 TLS]
        G[gitrust 127.0.0.1:4000
+ 0.0.0.0:2222]
        PG[(PostgreSQL 127.0.0.1:5432)]
        FS[/opt/gitrust/data/repos]
    end

    CLI -->|HTTPS :443| NGX
    CLI -->|SSH :2222| G
    NGX -->|proxy_pass| G
    G --> PG
    G --> FS

Caractéristiques : - Nginx termine TLS et proxifie vers gitrust sur 127.0.0.1:4000 - PostgreSQL accessible uniquement en local - Dépôts bare sur le disque local (ou volume attaché) - Un seul processus gitrust, un seul PostgreSQL - Sauvegarde avec pg_dump + rsync nocturne vers stockage externe

Dimensionnement indicatif :

Limites : point de défaillance unique — si le serveur tombe, tout tombe. Acceptable si RTO < 1 h (restauration depuis sauvegarde sur nouvelle VM).

Topologie 3 — Haute disponibilité (HA)¶

graph LR
    subgraph "Internet"
        CLI[Navigateurs / git clients]
    end

    subgraph "Load balancer"
        LB[HAProxy / Nginx LB
:443 + :2222]
    end

    subgraph "Backends gitrust"
        G1[gitrust-1 :4000 + :2222]
        G2[gitrust-2 :4000 + :2222]
    end

    subgraph "Données partagées"
        PG[(PostgreSQL primaire
+ réplica lecture)]
        NFS[Volume partagé NFS
ou S3-compatible]
    end

    CLI --> LB
    LB --> G1
    LB --> G2
    G1 --> PG
    G2 --> PG
    G1 --> NFS
    G2 --> NFS

Caractéristiques : - Plusieurs instances gitrust derrière un load balancer - PostgreSQL en mode primary/replica (streaming replication) - SESSION_BACKEND=redis obligatoire (sessions partagées entre instances) - Dépôts bare sur volume partagé (NFS, CEPH, ou objet S3 via FUSE)

Limites de la mise à l'échelle horizontale¶

Workers stateful¶

Les workers CI et Import sont des goroutines async dans le processus gitrust. Leur état (pipelines en cours, file d'attente) n'est pas partagé entre instances. En HA, il faut s'assurer qu'un seul nœud exécute les workers CI, ou accepter que des pipelines soient redémarrés si le nœud tombe.

Contournement actuel : désigner un nœud « primary » pour les workers (CI_ENABLED=true sur un seul nœud, CI_ENABLED=false sur les autres).

Dépôts bare sur volume partagé¶

Les dépôts Git bare doivent être accessibles depuis tous les nœuds gitrust. Options : - NFS : simple, suffisant pour la plupart des cas, mais latence réseau visible sur les gros push - CEPH / GlusterFS : haute performance distribuée, complexité opérationnelle élevée - S3-compatible (s3fs/mountpoint) : économique pour l'archivage, trop lent pour les accès Git fréquents - Réplication rsync en quasi-temps-réel : simple mais non-atomique (risque de dépôt corrompu pendant une réplication)

Recommandation : pour la grande majorité des équipes (< 50 personnes), la topologie mono-machine avec une bonne stratégie de sauvegarde offre un rapport complexité/disponibilité bien meilleur que la HA.

PostgreSQL en réplication¶

La réplication streaming PostgreSQL (primary/replica) est bien documentée et fiable. Le failover automatique nécessite un outil supplémentaire (Patroni, repmgr). Sans failover automatique, la HA PostgreSQL n'apporte qu'un RPO bas (perte de données minimale), pas un RTO bas (indisponibilité réduite).

Alternatives et compromis¶

Pour la cible principale de gitrust (équipes de 3-20 personnes) : la topologie mono-machine avec sauvegarde quotidienne offre un RTO acceptable. Investissez plutôt dans une bonne stratégie de sauvegarde que dans une architecture HA complexe.

Vérifier votre compréhension¶

1. Votre équipe passe de 10 à 40 personnes. Quels indicateurs surveilleriez-vous sur votre serveur mono-machine pour décider si une migration vers la HA est nécessaire ?

2. En topologie HA avec deux nœuds gitrust et un volume NFS partagé, quel est le scénario de défaillance qui ne peut pas être résolu par la HA seule ? Que faut-il prévoir en plus ?

Pour aller plus loin¶

• Architecture globale — composants et flux
• Stratégie de sauvegarde — 3-2-1 adapté à gitrust
• Ports et services
• Variables d'environnement — SESSION_BACKEND, REDIS_URL