> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/on-premises/fr/maintenance/horizontal-scaling.md).

# la mise à l’échelle horizontale

À partir de la version 3.5.6, Server Pro prend en charge la mise à l'échelle horizontale.

Ce document répertorie les exigences techniques et fournit des directives pour exécuter Server Pro sur plus d'un nœud.

{% hint style="danger" %}
À partir de Server CE/Server Pro `5.0.3` les variables d'environnement ont été renommées de `SHARELATEX_*` à `OVERLEAF_*`.

Si vous utilisez une `4.x` version (ou antérieure), veuillez vous assurer que les variables sont préfixées en conséquence (par ex. `SHARELATEX_SITE_URL` au lieu de `OVERLEAF_SITE_URL`)
{% endhint %}

La configuration d'une mise à l'échelle horizontale demande un effort considérable. Nous vous conseillons d'envisager la mise à l'échelle horizontale **uniquement** lorsque vous atteignez une certaine taille. À titre d'exemple, une installation de Server Pro pour 1 000 utilisateurs au total a été mise en place avec succès à l'aide d'un seul serveur équipé de deux processeurs à 4 cœurs et de 32 Go de mémoire système. Consultez la documentation sur les [exigences matérielles](/on-premises/fr/premiers-pas/requirements/hardware-requirements.md) pour obtenir des recommandations.

Un déploiement de Server Pro avec mise à l'échelle horizontale implique un ensemble de composants externes, tels qu'un équilibreur de charge et un backend de stockage compatible S3.

Nous pouvons aider à résoudre les erreurs dans les conteneurs Server Pro qui pourraient être dues à une mauvaise configuration et fournir des conseils généraux basés sur ce document. Malheureusement, nous ne sommes pas en mesure d'aider à configurer des applications/systèmes tiers.

La résolution de problèmes techniques propres à votre matériel/logiciel pour fournir les composants externes n'est pas couverte par nos conditions de support.

### Exigences

#### Stockage de données externe et centralisé

Le stockage des données dans Server Pro peut être réparti en quatre magasins de données :

* **MongoDB**

  * La plupart des données sont persistées dans MongoDB.
  * Nous prenons en charge soit une instance locale, soit une instance externe, telle que [MongoDB](https://www.mongodb.com/atlas) Atlas (un service MongoDB entièrement géré qui s'exécute dans l'infrastructure AWS).<br>

  **Remarque :** Malheureusement, il n'existe pour le moment aucun support officiel pour les bases de données compatibles MongoDB telles que CosmoDB/DocumentDB, car nous n'avons pas testé Server Pro avec elles. Bien que le déploiement de Server Pro avec des bases de données compatibles **puisse** être possible, nous ne prenons officiellement en charge que les déploiements utilisant MongoDB.<br>
* **Redis**

  * Redis stocke des données temporaires, comme les mises à jour de documents en attente avant leur écriture dans MongoDB.
  * Redis est utilisé pour communiquer les mises à jour de documents entre différents services et pour notifier l'éditeur des changements d'état dans un projet donné.
  * Redis est utilisé pour stocker les sessions utilisateur.
  * Nous prenons en charge soit une instance locale, soit une instance externe.<br>

  **Remarque :** Malheureusement, il n'existe pour le moment aucun support officiel pour les magasins clé/valeur compatibles Redis tels que KeyDB/Valkey, car nous n'avons pas testé Server Pro avec eux. Bien que le déploiement de Server Pro avec des magasins compatibles **puisse** puisse être possible, nous ne prenons officiellement en charge que les déploiements utilisant Redis.<br>
* **Fichiers de projet et fichiers d'historique**

  * Les fichiers de projet non modifiables sont stockés en dehors de MongoDB.

    Le nouveau système d'historique des projets (à partir de Server Pro 3.5) stocke également l'historique en dehors de MongoDB.
  * Pour les petites instances uniques, nous prenons en charge soit un système de fichiers local (qui peut s'appuyer sur un SSD local, NFS ou EBS), soit un [système de stockage de données compatible S3](/on-premises/fr/configuration/overleaf-toolkit/s3.md).
  * Pour la mise à l'échelle horizontale, nous **uniquement** prenons en charge les systèmes de stockage de données compatibles S3.<br>

  **Important :** NFS/Amazon EFS/Amazon EBS sont **ne pas** pris en charge pour la mise à l'échelle horizontale. Veuillez consulter la section [stockage matériel](/on-premises/fr/premiers-pas/requirements/hardware-requirements.md#storage) sur les exigences de mise à l'échelle du stockage dans Server Pro pour plus de détails.
* **Fichiers éphémères**
  * Les compilations LaTeX doivent s'exécuter sur des disques locaux rapides pour des performances optimales. Le résultat de la compilation n'a pas besoin d'être persisté ou sauvegardé.
  * La mise en tampon des nouveaux téléversements de fichiers et la création de fichiers zip de projet bénéficient également de l'utilisation d'un disque local.

{% hint style="danger" %}
Nous conseillons vivement d'utiliser un disque local. L'utilisation de tout type de disque réseau (comme NFS ou EBS) peut entraîner des erreurs de compilation inattendues et d'autres problèmes de performances.
{% endhint %}

#### **Git-bridge**

{% hint style="info" %}
Git-bridge est disponible dans Server Pro à partir de la version 4.0.1.
{% endhint %}

Les dépôts git sont stockés localement sur disque. Aucune option de réplication n'est disponible. Git-bridge doit être exécuté comme un **singleton**. Pour des performances optimales, nous conseillons d'utiliser un disque local pour les données de git-bridge. Le disque de données de git-bridge doit être sauvegardé régulièrement.

Pour le stockage des données avec mise à l'échelle horizontale, vous avez besoin de :

* une instance MongoDB centrale accessible depuis toutes les instances Server Pro
* une instance Redis centrale accessible depuis toutes les instances Server Pro
* un backend de stockage central compatible S3 pour les fichiers de projet et d'historique
* un disque local sur chaque instance pour les fichiers éphémères
* un disque local sur l'instance qui héberge le conteneur git-bridge pour les données de git-bridge

#### Exigences de l'équilibreur de charge

* **Routage persistant**, par ex. à l'aide d'un cookie

  Cette exigence provient de ces composants :

  * La fonctionnalité d'édition en temps réel dans Server Pro utilise WebSockets avec un repli vers le sondage XHR. Chaque session d'édition a un état local côté serveur et les requêtes d'une session d'édition donnée doivent toujours être routées vers la même instance Server Pro. La fonctionnalité de collaboration utilise Redis [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) pour partager les mises à jour entre plusieurs instances Server Pro.
  * La compilation LaTeX conserve localement la sortie et le cache de compilation pour des performances optimales. Lorsqu'une requête de compilation est envoyée à une instance Server Pro, les requêtes de téléchargement PDF/journal suivantes doivent être routées vers la même instance Server Pro.
* **Délais d'attente longs pour les requêtes** pour prendre en charge la compilation de grands documents LaTeX
* **Prise en charge de WebSocket** pour des performances optimales
* **taille de charge utile POST de 50 Mo**
* **Délai d'attente keep-alive** doit être inférieur au délai d'attente keep-alive de Server Pro

  Le délai d'attente keep-alive dans Server Pro peut être configuré à l'aide de la variable d'environnement `NGINX_KEEPALIVE_TIMEOUT`. La valeur par défaut est 65 s.

  Avec la valeur par défaut, un délai d'attente keep-alive de 60 s dans l'équilibreur de charge fonctionne.

  Avec `NGINX_KEEPALIVE_TIMEOUT=120`, l'équilibreur de charge pourrait choisir 115 s.
* **Adresses IP client**

  Définissez l'en-tête de requête `X-Forwarded-For` sur l'adresse IP du client.
* Lorsque **terminant le SSL**

  L'équilibreur de charge doit ajouter l'en-tête de requête `X-Forwarded-Proto: https`.

<details>

<summary>Exemple de configuration HAProxy</summary>

```
global
  groupe haproxy
  utilisateur haproxy

  # Journalisation verbeuse
  log stdout format raw local0 debug

defaults
  mode                    http
  option                  httpchk HEAD /status
  http-check              expect status 200
  default-server          check

  # Journalisation verbeuse
  log                     global
  option                  httplog

  # Rediriger vers un backend différent si celui avec affinité est en panne
  option                  redispatch 1
  # Ces tentatives de reconnexion concernent les erreurs de connexion TCP, pas les réponses HTTP 500
  retries                 3

  # Session persistante pendant 24 h d'inactivité -- la sortie de compilation est supprimée après 24 h
  cookie                  server-pro-ha insert maxidle 24h

  # Essayer de se connecter à n'importe quel backend pendant 1 min, puis renvoyer 503
  timeout queue           1m
  # Donner aux instances Server Pro 15 s pour démarrer
  timeout connect         15s

  # Interrompre les requêtes des clients très lents (autoriser 1 min d'inactivité lors de la lecture d'une requête)
  timeout client          1m

  # Autoriser les compilations lentes -- la limite codée en dur dans clsi est de 10 min
  timeout server          10m

  # Déconnecter l'éditeur après 23 h -- 1 h avant sa dernière utilisation hier
  timeout tunnel          23h

  # Remarque : le comportement keepalive dans haproxy fonctionne très bien avec la configuration keepalive par défaut dans Server Pro.
  #       Haproxy nettoie les connexions en arrière-plan et redirigera les requêtes lorsque nécessaire.

listen server-pro-ha-http
  bind :80
  http-request redirect scheme https unless { ssl_fc }

listen server-pro-ha-https
  bind :443 ssl crt /etc/ssl/certs/ssl-key-and-certificate-bundle.pem

  # Indiquer à l'application que nous sommes derrière https
  http-request set-header X-Forwarded-Proto https

  # Indiquer à l'application l'adresse IP réelle du client
  option forwardfor

  # Voir https://hstspreload.org/#deployment-recommendations
  http-response set-header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload;"

  # Routage du trafic git vers le conteneur frère de git-bridge
  use-server server-pro-ha-1 if { path_beg /git/ }

  # Débogage
  http-response add-header X-Served-By %s
  stats enable
  stats uri /haproxy

  server server-pro-ha-1 198.18.1.1:80 cookie server-pro-ha-1
  server server-pro-ha-2 198.18.1.2:80 cookie server-pro-ha-2
  server server-pro-ha-3 198.18.1.3:80 cookie server-pro-ha-3
```

</details>

#### Configuration de Server Pro

**Secrets**

Les instances Server Pro doivent s'entendre sur des secrets partagés :

* `WEB_API_PASSWORD` (authentification de l'API web)
* `STAGING_PASSWORD` et `V1_HISTORY_PASSWORD` même valeur (authentification de l'historique)
* `CRYPTO_RANDOM` (pour le cookie de session)
* `OT_JWT_AUTH_KEY` (authentification de l'historique)

Tous ces secrets doivent être configurés avec leur propre valeur unique et partagés entre les instances.

Lorsqu'ils ne sont pas configurés et que les requêtes des utilisateurs sont routées vers différentes instances Server Pro, leur authentification échouera et ils seront fréquemment redirigés vers la page de connexion ou leurs actions dans l'interface échoueront de manière inattendue.

Lorsqu'ils ne sont pas configurés, Server Pro utilise une nouvelle valeur aléatoire pour chaque secret, basée sur 32 octets aléatoires provenant de `/dev/urandom` (256 bits aléatoires).

{% code overflow="wrap" %}

```bash
# https://github.com/overleaf/overleaf/blob/45ca0f796c679103efd305ddbef28073c4a5de32/server-ce/init_scripts/00_regen_sharelatex_secrets.sh#L14
dd if=/dev/urandom bs=1 count=32 2>/dev/null | base64 -w 0 | rev | cut -b 2- | rev | tr -d '\n+/'
```

{% endcode %}

**MongoDB**

Pointez `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` pour les versions `4.x` et antérieures) sur l'instance MongoDB centrale.

**Redis**

Pointez `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` pour les versions `4.x` et antérieures) et `REDIS_HOST` sur l'instance Redis centrale.

**Stockage compatible S3 pour les fichiers de projet et d'historique**

Veuillez consulter la documentation sur [le stockage compatible S3](/on-premises/fr/configuration/overleaf-toolkit/s3.md) pour plus de détails.

**Fichiers éphémères**

Le montage par liaison par défaut d'un SSD local vers `/var/lib/overleaf` (`/var/lib/sharelatex` pour les versions `4.x` et antérieures) suffira. Veillez à pointer `SANDBOXED_COMPILES_HOST_DIR` vers le point de montage sur l'hôte.

{% hint style="danger" %}
Nous conseillons vivement d'utiliser un disque local. L'utilisation de tout type de disque réseau (comme NFS ou EBS) peut entraîner des erreurs de compilation inattendues et d'autres problèmes de performances.
{% endhint %}

**Configuration du proxy**

* Définissez `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` pour les versions `4.x` et antérieures) pour obtenir des adresses IP client exactes.
* Définissez `TRUSTED_PROXY_IPS` sur l'adresse IP de l'équilibreur de charge (plusieurs CIDR peuvent être spécifiés, séparés par une virgule).

**Intégration de Git-bridge**

{% hint style="info" %}
Git-bridge est disponible dans Server Pro à partir de la version 4.0.1.
{% endhint %}

Le conteneur git-bridge a besoin d'un conteneur Server Pro frère pour gérer les requêtes git entrantes. Ce conteneur frère peut également servir le trafic utilisateur normal. Dans la configuration d'exemple, la première instance agit comme conteneur frère pour git-bridge, mais n'importe quelle instance pourrait vraiment remplir ce rôle.

Pourquoi devons-nous désigner un conteneur Server Pro comme frère pour git-bridge ? Server Pro fournit des URL de téléchargement pour le service d'historique à git-bridge. Nous devons configurer ces URL d'historique de sorte qu'elles soient accessibles depuis le conteneur git-bridge.

Configuration du conteneur Server Pro :

* Définissez `GIT_BRIDGE_ENABLED` à `'true'`
* Définissez `GIT_BRIDGE_HOST` à `<nom du conteneur git-bridge>` par ex. `git-bridge`
* Définissez `GIT_BRIDGE_PORT` à `8000`
* Définissez `V1_HISTORY_URL` à `http://<nom du conteneur frère server-pro>:3100/api`.

  Remarque : ceci n'est nécessaire que sur le conteneur frère du conteneur git-bridge. Les autres instances peuvent utiliser une URL localhost, qui est la valeur par défaut.

Configuration du conteneur git-bridge :

* Définissez `GIT_BRIDGE_API_BASE_URL` à `http://<nom du conteneur frère server-pro>/api/v0`, par ex. `http://server-pro-ha-1/api/v0`
* Définissez `GIT_BRIDGE_OAUTH2_SERVER` à `http://<nom du conteneur frère server-pro>`, par ex. `http://server-pro-ha-1`
* Définissez `GIT_BRIDGE_POSTBACK_BASE_URL` à `http://<nom du conteneur git-bridge>:8000`, par ex. `http://git-bridge:8000`
* Définissez `GIT_BRIDGE_ROOT_DIR` vers le disque de données git-bridge monté en liaison, par ex. `/data/git-bridge`

<details>

<summary>Exemple de configuration docker-compose.yml</summary>

La configuration suivante montre une installation autonome. Pour que la démonstration fonctionne, vous devez fournir une clé/certificat SSL valide et ajuster les `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` pour les versions `4.x` et antérieures). Pour une véritable installation, vous devez remplacer les secrets factices par des secrets réels comme indiqué en ligne. Pour une véritable installation, vous devez déplacer les conteneurs individuels sur des nœuds dédiés et ajuster les adresses IP à votre configuration réseau locale.

```yaml
version: '2.2'

# Configuration réelle de mise à l'échelle horizontale : choisissez votre propre réseau et remplacez les IP dans la configuration.
réseaux :
    par défaut :
        ipam :
            config :
                # Ce sous-réseau fait partie d'un sous-réseau réservé utilisé pour le benchmarking
                # https://tools.ietf.org/html/rfc2544
                # Le sous-réseau complet est 198.18.0.0/15
                # Utilisez 198.18.0.0/24 pour lb et dbs
                # Utilisez 198.18.1.0/24 pour server-pro
                # Utilisez 198.18.0.128/25 pour le conteneur éphémère
                - passerelle : 198.18.0.1
                  plage_ip : 198.18.0.128/25
                  sous-réseau : 198.18.0.0/23

services:
    # Configuration réelle de mise à l'échelle horizontale : exécutez haproxy en dehors de docker sur un hôte séparé.
    lb :
        image : haproxy:2.6
        nom_du_conteneur : lb
        user: root
        journalisation :
            pilote : local
            options :
                taille_max : 10g
                fichier_max : '100'
        volumes:
            - ./haproxy.conf:/usr/local/etc/haproxy/haproxy.cfg
            # $ cat certificate.pem key.pem > ssl-key-and-certificate-bundle.pem
            - /path/to/ssl-key-and-certificate-bundle.pem:/etc/ssl/certs/ssl-key-and-certificate-bundle.pem
        # Alternative à "ports" : utilisez le réseau de l'hôte pour éviter la surcharge de docker-proxy
        mode_réseau : hôte

        # Alternative à "network_mode: host" : utilisez docker-proxy pour l'isolation réseau
        # ports :
        #     - "80:80"
        #     - "443:443"
        # réseaux :
        #     default :
        #         ipv4_address : 198.18.0.2

        # Configuration réelle de mise à l'échelle horizontale : supprimez ces éléments car ils s'exécutent sur d'autres hôtes.
        dépend_de :
            server-pro-ha-1 :
                condition : service_started
            server-pro-ha-2 :
                condition : service_started
            server-pro-ha-3 :
                condition : service_started

    # Configuration réelle de mise à l'échelle horizontale : exécutez ce conteneur à côté de server-pro-ha-1.
    # Pour Server Pro 4.0 et versions ultérieures.
    git-bridge :
        restart: always
        # La balise doit correspondre à la balise du conteneur `server-pro-ha-1`.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumes:
            # Configuration réelle de mise à l'échelle horizontale : pointez /data/git-bridge vers un SSD local dédié.
            - ~/git_bridge_data:/data/git-bridge
        container_name: git-bridge
        environment:
            GIT_BRIDGE_API_BASE_URL: "http://server-pro-ha-1/api/v0"
            GIT_BRIDGE_OAUTH2_SERVER: "http://server-pro-ha-1"
            GIT_BRIDGE_POSTBACK_BASE_URL: "http://198.18.0.6:8000"
            GIT_BRIDGE_ROOT_DIR: "/data/git-bridge"
        user: root
        command: ["/server-pro-start.sh"]

        # Configuration réelle de mise à l'échelle horizontale : exécutez sur l'hôte 198.18.0.6 et exposez le port
        # ports :
        #     - "8000:8000"
        réseaux :
            par défaut :
                ipv4_address: 198.18.0.6

    # Configuration réelle de mise à l'échelle horizontale : exécutez ce conteneur sur un hôte séparé.
    server-pro-ha-1: &server-pro-ha-config
        restart: always
        image: quay.io/sharelatex/sharelatex-pro:4.0.1
        nom_du_conteneur : server-pro-ha-1
        nom_d'hôte : server-pro-ha-1
        dépend_de :
            # Configuration réelle de mise à l'échelle horizontale : conservez cette entrée.
            git-bridge :
                condition : service_started

            # Configuration réelle de mise à l'échelle horizontale : supprimez celles ci-dessous car elles s'exécutent sur d'autres hôtes.
            mongo:
                condition : service_healthy
            redis:
                condition : service_started
            minio :
                condition : service_started
            mongo_replica_set_setup :
                condition : service_completed_successfully
            minio_setup :
                condition : service_completed_successfully
        stop_grace_period : 60s
        volumes:
            - /tmp/scratch-disk1:/var/lib/sharelatex
            - /var/run/docker.sock:/var/run/docker.sock
        environnement : &server-pro-ha-environment
            # Configuration réelle de mise à l'échelle horizontale : fournissez votre propre domaine/nom d'application.
            OVERLEAF_SITE_URL: 'https://overleaf.example.com'
            OVERLEAF_APP_NAME: Démonstration de mise à l'échelle horizontale de Server Pro

            OVERLEAF_MONGO_URL: mongodb://198.18.0.3/sharelatex
            OVERLEAF_REDIS_HOST: 198.18.0.4
            REDIS_HOST: 198.18.0.4

            ENABLED_LINKED_FILE_TYPES: 'project_file,project_output_file'
            EMAIL_CONFIRMATION_DISABLED: 'true'

            SANDBOXED_COMPILES: 'true'
            SANDBOXED_COMPILES_SIBLING_CONTAINERS: 'true'
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk1/data/compiles'

            # S3
            # Configuration réelle de mise à l'échelle horizontale : choisissez des identifiants sécurisés.
            OVERLEAF_FILESTORE_BACKEND: s3
            OVERLEAF_FILESTORE_USER_FILES_BUCKET_NAME: overleaf-user-files
            OVERLEAF_FILESTORE_TEMPLATE_FILES_BUCKET_NAME: overleaf-template-files
            OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID: OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID
            OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY: OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY
            OVERLEAF_FILESTORE_S3_ENDPOINT: http://198.18.0.5:9000
            OVERLEAF_FILESTORE_S3_PATH_STYLE: 'true'
            OVERLEAF_FILESTORE_S3_REGION: ''

            OVERLEAF_HISTORY_BACKEND: "s3"
            OVERLEAF_HISTORY_PROJECT_BLOBS_BUCKET: "overleaf-project-blobs"
            OVERLEAF_HISTORY_CHUNKS_BUCKET: "overleaf-chunks"
            OVERLEAF_HISTORY_S3_ACCESS_KEY_ID: "OVERLEAF_HISTORY_S3_ACCESS_KEY_ID"
            OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY: "OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY"
            OVERLEAF_HISTORY_S3_ENDPOINT: http://198.18.0.5:9000
            OVERLEAF_HISTORY_S3_PATH_STYLE: 'true'
            OVERLEAF_HISTORY_S3_REGION: ''
            # /S3

            # git-bridge
            GIT_BRIDGE_ENABLED: 'true'
            GIT_BRIDGE_HOST: 198.18.0.6
            GIT_BRIDGE_PORT: 8000
            # Requis uniquement sur l'instance sœur de git-bridge
            V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
            # /git-bridge

            # Mise à l'échelle horizontale
            # Configuration réelle de mise à l'échelle horizontale : choisissez des identifiants sécurisés.
            WEB_API_PASSWORD: WEB_API_PASSWORD
            STAGING_PASSWORD: V1_HISTORY_PASSWORD
            V1_HISTORY_PASSWORD: V1_HISTORY_PASSWORD
            CRYPTO_RANDOM: CRYPTO_RANDOM
            OT_JWT_AUTH_KEY: OT_JWT_AUTH_KEY
            OVERLEAF_BEHIND_PROXY: 'true'
            # Configuration réelle de la mise à l'échelle horizontale : adresses IP des équilibreurs de charge
            TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
            # /Mise à l'échelle horizontale

        # Configuration réelle de la mise à l'échelle horizontale : exécutez sur l'hôte 198.18.1.1 et exposez les ports
        # ports :
        #     - "80:80"
        réseaux :
            par défaut :
                ipv4_address: 198.18.1.1

    # Configuration réelle de mise à l'échelle horizontale : exécutez ce conteneur sur un hôte séparé.
    server-pro-ha-2 :
        <<: *server-pro-ha-config
        hostname: server-pro-ha-2
        container_name: server-pro-ha-2
        volumes:
            - /tmp/scratch-disk2:/var/lib/sharelatex
            - /var/run/docker.sock:/var/run/docker.sock
        environment:
            <<: *server-pro-ha-environment
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk2/data/compiles'
            V1_HISTORY_URL: "http://localhost:3100/api"

        # Configuration réelle de la mise à l'échelle horizontale : exécutez sur l'hôte 198.18.1.2 et exposez les ports
        # ports :
        #     - "80:80"
        réseaux :
            par défaut :
                ipv4_address: 198.18.1.2

    # Configuration réelle de mise à l'échelle horizontale : exécutez ce conteneur sur un hôte séparé.
    server-pro-ha-3 :
        <<: *server-pro-ha-config
        hostname: server-pro-ha-3
        container_name: server-pro-ha-3
        volumes:
            - /tmp/scratch-disk3:/var/lib/sharelatex
            - /var/run/docker.sock:/var/run/docker.sock
        environment:
            <<: *server-pro-ha-environment
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk3/data/compiles'
            V1_HISTORY_URL: "http://localhost:3100/api"

        # Configuration réelle de la mise à l'échelle horizontale : exécutez sur l'hôte 198.18.1.3 et exposez les ports
        # ports :
        #     - "80:80"
        réseaux :
            par défaut :
                ipv4_address: 198.18.1.3

    # Configuration réelle de mise à l'échelle horizontale : exécutez ce conteneur sur un hôte séparé.
    minio :
        image: minio/minio:RELEASE.2023-05-18T00-05-36Z
        container_name: minio
        command: server /data
        volumes:
            # Configuration réelle de la mise à l'échelle horizontale : faites fonctionner MinIO avec plusieurs disques, voir la documentation MinIO.
            - ~/minio_data:/data
        environment:
            # Configuration réelle de mise à l'échelle horizontale : choisissez des identifiants sécurisés.
            MINIO_ROOT_USER: MINIO_ROOT_USER
            MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

        # Configuration réelle de la mise à l'échelle horizontale : exécutez sur l'hôte 198.18.0.5 et exposez le port
        # ports :
        #     - "9000:9000"
        réseaux :
            par défaut :
                ipv4_address: 198.18.0.5

    # Configuration réelle de la mise à l'échelle horizontale : exécutez cette configuration une seule fois sur un hôte séparé.
    minio_setup :
        dépend_de :
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        commande :
            - '-c'
            # Configuration réelle de mise à l'échelle horizontale : choisissez des identifiants sécurisés.
            - |
                mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \
                || sleep 10 && \
                mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \
                || sleep 10 && \
                mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \
                || sleep 10 && \
                mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD

                mc mb --ignore-existing s3/overleaf-user-files
                mc mb --ignore-existing s3/overleaf-template-files
                mc admin user add s3 \\
                  OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID \\
                  OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY

                mc mb --ignore-existing s3/overleaf-project-blobs
                mc mb --ignore-existing s3/overleaf-chunks
                mc admin user add s3 \\
                  OVERLEAF_HISTORY_S3_ACCESS_KEY_ID \\
                  OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY

                echo '
                  {
                    "Version": "2012-10-17",
                    "Statement": [
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:ListBucket"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-user-files"
                      },
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:PutObject",
                          "s3:GetObject",
                          "s3:DeleteObject"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-user-files/*"
                      },
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:ListBucket"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-template-files"
                      },
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:PutObject",
                          "s3:GetObject",
                          "s3:DeleteObject"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-template-files/*"
                      }
                    ]
                  }' > policy-filestore.json

                echo '
                  {
                    "Version": "2012-10-17",
                    "Statement": [
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:ListBucket"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-project-blobs"
                      },
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:PutObject",
                          "s3:GetObject",
                          "s3:DeleteObject"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-project-blobs/*"
                      },
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:ListBucket"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-chunks"
                      },
                      {
                        "Effect": "Allow",
                        "Action": [
                          "s3:PutObject",
                          "s3:GetObject",
                          "s3:DeleteObject"
                        ],
                        "Resource": "arn:aws:s3:::overleaf-chunks/*"
                      }
                    ]
                  }' > policy-history.json

                # Placez le contenu de la politique de la section précédente dans policy-filestore.json
                # Rappel : remplacez les noms des buckets en conséquence.
                mc admin policy create s3 overleaf-filestore policy-filestore.json
                mc admin policy attach s3 overleaf-filestore \\
                  --user=OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID || true

                mc admin policy create s3 overleaf-history policy-history.json
                mc admin policy attach s3 overleaf-history \\
                  --user=OVERLEAF_HISTORY_S3_ACCESS_KEY_ID || true

    # Configuration réelle de mise à l'échelle horizontale : exécutez ce conteneur sur un hôte séparé.
    mongo:
        restart: always
        image: mongo:4.4
        container_name: mongo
        command: "--replSet overleaf"
        expose :
            - 27017
        volumes:
            - ~/mongo_data:/data/db
        healthcheck:
            test: echo 'db.stats().ok' | mongo localhost:27017/test --quiet
            interval: 10s
            timeout: 10s
            retries: 5

        # Configuration réelle de la mise à l'échelle horizontale : exécutez sur l'hôte 198.18.0.3 et exposez le port
        # ports :
        #     - "27017:27017"
        réseaux :
            par défaut :
                ipv4_address: 198.18.0.3

    mongo_replica_set_setup :
        image: mongo:4.4
        entrypoint: sh
        dépend_de :
            mongo:
                condition : service_healthy
        commande :
            - '-c'
            - |
                mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

    # Configuration réelle de mise à l'échelle horizontale : exécutez ce conteneur sur un hôte séparé.
    redis:
        restart: always
        image: redis:6.2
        container_name: redis
        expose :
            - 6379
        volumes:
            - ~/redis_data:/data

        # Configuration réelle de la mise à l'échelle horizontale : exécutez sur l'hôte 198.18.0.4 et exposez le port
        # ports :
        #     - "6379:6379"
        réseaux :
            par défaut :
                ipv4_address: 198.18.0.4
```

</details>

#### Matériel

Nous recommandons d'utiliser les mêmes spécifications matérielles pour toutes les instances Server Pro participant à la mise à l'échelle horizontale.

Les recommandations générales concernant [les spécifications matérielles](/on-premises/fr/premiers-pas/requirements/hardware-requirements.md) pour les instances Server Pro s'appliquent.

#### Mise à niveau de Server Pro

Dans le cadre du processus de mise à niveau, Server Pro exécute automatiquement des migrations de base de données. Ces migrations sont **ne pas** conçues pour être exécutées depuis plusieurs instances en parallèle.

Les migrations doivent se terminer avant le démarrage de l'application web proprement dite. Vous pouvez soit vérifier dans les journaux la présence d'une entrée de `Migrations terminées` ou attendre que l'application accepte le trafic.

La procédure de mise à niveau est la suivante :

1. Planifiez une fenêtre de maintenance
2. Arrêtez toutes les instances de Server Pro
3. Effectuez une sauvegarde cohérente comme décrit dans le [documentation](/on-premises/fr/maintenance/data-and-backups.md#performing-a-consistent-backup)
4. Démarrez une seule instance de Server Pro avec la nouvelle version
5. Vérifiez que la nouvelle instance fonctionne comme prévu
6. Démarrez les autres instances avec la nouvelle version


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://overleaf-pro.ayaka.space/on-premises/fr/maintenance/horizontal-scaling.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.