> For the complete documentation index, see [llms.txt](https://ayakaleaf-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://ayakaleaf-pro.ayaka.space/on-premises/fr/maintenance/horizontal-scaling.md).

# Mise à l’échelle horizontale

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

Ce document liste 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 mise en place d’une mise à l’échelle horizontale demande un effort important. Nous conseillons d’envisager la mise à l’échelle horizontale **uniquement** lorsque vous atteignez une certaine échelle. À titre d’exemple, une installation 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 [configuration matérielle](/on-premises/fr/demarrage/requirements/hardware-requirements.md) documentation pour 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 à diagnostiquer les erreurs dans les conteneurs Server Pro qui pourraient résulter d’une mauvaise configuration et fournir des conseils généraux basés sur ce document. Malheureusement, nous ne pouvons pas fournir d’assistance pour la configuration d’applications/systèmes tiers.

La résolution des problèmes techniques spécifiques à votre matériel/logiciel pour fournir les composants externes n’est pas couverte par nos conditions d’assistance.

### Exigences

#### Stockage de données externe, central

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 aucune prise en charge officielle des bases de données compatibles MongoDB telles que CosmoDB/DocumentDB, car nous n’avons pas testé Server Pro avec elles. Bien qu’un 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 document en attente avant leur écriture dans MongoDB.
  * Redis est utilisé pour communiquer les mises à jour de document entre différents services et 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 aucune prise en charge officielle des magasins clé/valeur compatibles Redis tels que KeyDB/Valkey, car nous n’avons pas testé Server Pro avec eux. Bien qu’un 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 de projet (Server Pro 3.5 et versions ultérieures) 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 être hébergé 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 des 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 [stockage matériel](/on-premises/fr/demarrage/requirements/hardware-requirements.md#storage) section des exigences sur la 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 conservé de façon persistante ni sauvegardé.
  * La mise en mémoire 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 déconseillons fortement l’utilisation d’un disque local. L’utilisation de tout type de disque réseau (tel que NFS ou EBS) peut entraîner des erreurs de compilation inattendues et d’autres problèmes de performance.
{% 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 git-bridge

#### Exigences pour l’équilibreur de charge

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

  Cette exigence découle de ces composants :

  * La fonctionnalité d’édition en temps réel dans Server Pro utilise WebSockets avec un repli vers l’interrogation 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 acheminé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. Lors de l’émission d’une demande de compilation vers une instance Server Pro, les demandes de téléchargement de PDF/journal suivantes doivent être acheminées vers la même instance Server Pro.
* **Délais d’expiration des requêtes longs** pour prendre en charge la compilation de gros documents LaTeX
* **Prise en charge de WebSocket** pour des performances optimales
* **charge utile POST de 50 Mo**
* **Délai keep-alive** doit être inférieur au délai keep-alive de Server Pro

  Le délai 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 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’IP du client.
* Lorsque **terminaison 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
  group haproxy
  user 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 autre backend si celui persistant est hors service
  option                  redispatch 1
  # Ces tentatives ne concernent que 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
  # Laisser 15 s aux instances Server Pro 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 de Server Pro.
  #       Haproxy nettoie les connexions en arrière-plan et redirigera les requêtes si 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;"

  # Acheminer le 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’accorder 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 acheminées vers différentes instances Server Pro, leur requête échouera aux vérifications d’authentification et ils seront soit fréquemment redirigés vers la page de connexion, soit leurs actions dans l’interface utilisateur é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 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**

Indiquez `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` pour les versions `4.x` et antérieures) à l’instance centrale MongoDB.

**Redis**

Indiquez `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` pour les versions `4.x` et antérieures) et `REDIS_HOST` à l’instance centrale Redis.

**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 défaut d’un SSD local sur `/var/lib/overleaf` (`/var/lib/sharelatex` pour les versions `4.x` et antérieures) suffira. Veillez à faire pointer `SANDBOXED_COMPILES_HOST_DIR` vers le point de montage sur l’hôte.

{% hint style="danger" %}
Nous déconseillons fortement l’utilisation d’un disque local. L’utilisation de tout type de disque réseau (tel que NFS ou EBS) peut entraîner des erreurs de compilation inattendues et d’autres problèmes de performance.
{% endhint %}

**Configuration du proxy**

* Définissez `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` pour les versions `4.x` et antérieures) pour des IP client exactes.
* Définissez `TRUSTED_PROXY_IPS` sur l’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 frère Server Pro pour traiter 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 en réalité remplir ce rôle.

Pourquoi devons-nous désigner un conteneur Server Pro comme conteneur frère pour git-bridge ? Server Pro remet les URL de téléchargement pour le service d’historique à git-bridge. Nous devons configurer ces URL d’historique pour 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 pour le 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 exemple `http://server-pro-ha-1/api/v0`
* Définissez `GIT_BRIDGE_OAUTH2_SERVER` à `http://<nom du conteneur frère server-pro>`, par exemple `http://server-pro-ha-1`
* Définissez `GIT_BRIDGE_POSTBACK_BASE_URL` à `http://<nom du conteneur git-bridge>:8000`, par exemple `http://git-bridge:8000`
* Définissez `GIT_BRIDGE_ROOT_DIR` vers le disque de données git-bridge monté par bind, 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émo 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 installation réelle, vous devez remplacer les secrets factices par de vrais secrets comme indiqué en ligne. Pour une installation réelle, 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'

# Installation réelle de mise à l’échelle horizontale : choisissez votre propre réseau et remplacez les IPs dans la configuration.
networks:
    default:
        ipam:
            config:
                # Ce sous-réseau fait partie d’un sous-réseau réservé aux tests de performance
                # 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
                - gateway: 198.18.0.1
                  ip_range: 198.18.0.128/25
                  subnet: 198.18.0.0/23

services :
    # Installation 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
        container_name: lb
        user: root
        logging:
            driver: local
            options:
                max-size: 10g
                max-file: '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 hôte pour éviter la surcharge de docker-proxy
        network_mode: host

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

        # Installation réelle de mise à l’échelle horizontale : supprimez-les car ils s’exécutent sur d’autres hôtes.
        depends_on:
            server-pro-ha-1:
                condition: service_started
            server-pro-ha-2:
                condition: service_started
            server-pro-ha-3:
                condition: service_started

    # Installation réelle de mise à l’échelle horizontale : exécutez ce conteneur à côté de server-pro-ha-1.
    # À partir de Server Pro 4.0.
    git-bridge:
        restart: always
        # Le tag doit correspondre au tag du conteneur `server-pro-ha-1`.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumes:
            # Installation réelle de mise à l’échelle horizontale : faites pointer /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"]

        # Installation réelle de mise à l’échelle horizontale : exécutez sur l’hôte 198.18.0.6 et exposez le port
        # ports:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Installation 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
        container_name: server-pro-ha-1
        hostname: server-pro-ha-1
        depends_on:
            # Installation réelle de mise à l’échelle horizontale : conservez cette entrée.
            git-bridge:
                condition: service_started

            # Installation 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
        environment: &server-pro-ha-environment
            # Installation 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émo 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
            # Installation 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
            # N'est nécessaire que sur l'instance sœur de git-bridge
            V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
            # /git-bridge

            # Mise à l'échelle horizontale
            # Installation 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 : IP des répartiteurs 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écuter sur l'hôte 198.18.1.1 et exposer les ports
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.1

    # Installation 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écuter sur l'hôte 198.18.1.2 et exposer les ports
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.2

    # Installation 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écuter sur l'hôte 198.18.1.3 et exposer les ports
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.3

    # Installation 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 : exécuter minio avec plusieurs disques, voir la documentation de minio.
            - ~/minio_data:/data
        environment:
            # Installation 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écuter sur l'hôte 198.18.0.5 et exposer le port
        # ports:
        #     - "9000:9000"
        networks:
            default:
                ipv4_address: 198.18.0.5

    # Configuration réelle de la mise à l'échelle horizontale : exécuter cette configuration une seule fois sur un hôte distinct.
    minio_setup:
        depends_on:
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        commande :
            - '-c'
            # Installation 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

                # Mettez 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

    # Installation 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écuter sur l'hôte 198.18.0.3 et exposer le port
        # ports:
        #     - "27017:27017"
        networks:
            default:
                ipv4_address: 198.18.0.3

    mongo_replica_set_setup:
        image: mongo:4.4
        entrypoint: sh
        depends_on:
            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\" } ] })"

    # Installation 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écuter sur l'hôte 198.18.0.4 et exposer le port
        # ports:
        #     - "6379:6379"
        networks:
            default:
                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 qui participent à la mise à l'échelle horizontale.

Les recommandations générales sur [les spécifications matérielles](/on-premises/fr/demarrage/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 en parallèle depuis plusieurs instances.

Les migrations doivent se terminer avant le démarrage de la véritable application web. 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 du trafic.

La procédure de mise à niveau ressemble à ceci :

1. Planifier une fenêtre de maintenance
2. Arrêter toutes les instances de Server Pro
3. Prendre une sauvegarde cohérente comme décrit dans la [documentation](/on-premises/fr/maintenance/data-and-backups.md#performing-a-consistent-backup)
4. Démarrer une seule instance de Server Pro avec la nouvelle version
5. Valider que la nouvelle instance fonctionne comme prévu
6. Mettre en service 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://ayakaleaf-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.