> ## Documentation Index
> Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Mise à l'échelle horizontale

<Check>
  Ayakaleaf Pro prend en charge la mise à l'échelle horizontale. Nous avons testé et vérifié qu'il fonctionne correctement avec plusieurs réplicas.
</Check>

Ce document présente les exigences techniques et fournit des recommandations pour exécuter Ayakaleaf Pro sur plus d'un nœud.

<Danger>
  À partir de Server CE/Server Pro `5.0.3`, les variables d'environnement ont été renommées de `SHARELATEX_*` en `OVERLEAF_*`.

  Si vous utilisez une version `4.x` (ou antérieure), assurez-vous que les variables portent le préfixe correspondant (par exemple `SHARELATEX_SITE_URL` au lieu de `OVERLEAF_SITE_URL`)
</Danger>

La mise en place de la mise à l'échelle horizontale demande un effort considérable. Nous vous conseillons de n'envisager la mise à l'échelle horizontale \*\*qu'\*\*à partir d'une certaine taille. À titre d'exemple, une installation Server Pro pour 1 000 utilisateurs au total a été mise en place avec succès sur un seul serveur équipé de deux processeurs à 4 cœurs et de 32 Go de mémoire système. Consultez la documentation sur la [configuration matérielle requise](/fr/on-premises/getting-started/requirements/hardware-requirements) pour nos recommandations.

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

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

La résolution des problèmes techniques propres au matériel ou aux logiciels que vous utilisez pour fournir les composants externes n'est pas couverte par nos conditions de support.

### Prérequis

<Frame>
  <img src="https://mintcdn.com/ayakaleaf-pro/GmaXa-Cu4QQRFT4C/images/on-premises/img-f045c922.jpg?fit=max&auto=format&n=GmaXa-Cu4QQRFT4C&q=85&s=fc2eadc84a202a5ad07dd34ca6f903d4" alt="" width="2617" height="2319" data-path="images/on-premises/img-f045c922.jpg" />
</Frame>

#### 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 une instance locale ou une instance externe, comme [MongoDB](https://www.mongodb.com/atlas) Atlas (un service MongoDB entièrement géré qui s'exécute au sein de l'infrastructure AWS).<br />

  <strong>Remarque :</strong> malheureusement, il n'existe pour l'instant 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 celles-ci. Même s'il **peut** être possible de déployer Server Pro avec des bases de données compatibles, 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 sert à communiquer les mises à jour de documents entre les différents services et à notifier l'éditeur des changements d'état d'un projet donné.
  * Redis sert à stocker les sessions utilisateur.
  * Nous prenons en charge une instance locale ou une instance externe.<br />

  <strong>Remarque :</strong> malheureusement, il n'existe pour l'instant aucune prise en charge officielle des magasins clé/valeur compatibles Redis tels que KeyDB/Valkey, car nous n'avons pas testé Server Pro avec ceux-ci. Même s'il **peut** être possible de déployer Server Pro avec des magasins compatibles, 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 un système de fichiers local (qui peut reposer sur un SSD local, NFS ou EBS) ou un [système de stockage de données compatible S3](/fr/on-premises/configuration/overleaf-toolkit/s3).
  * Pour la mise à l'échelle horizontale, nous prenons en charge **uniquement** les systèmes de stockage de données compatibles S3.<br />

  <strong>Important :</strong> NFS/Amazon EFS/Amazon EBS ne sont **pas** pris en charge pour la mise à l'échelle horizontale. Consultez la section sur le [stockage matériel](/fr/on-premises/getting-started/requirements/hardware-requirements#storage) des prérequis concernant 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 persisté ni sauvegardé.
  * La mise en mémoire tampon des nouveaux fichiers téléversés et la création des archives zip de projets bénéficient également d'un disque local.

<Danger>
  Nous vous 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.
</Danger>

#### **Git-bridge**

<Info>
  Git-bridge est disponible dans Server Pro à partir de la version 4.0.1.
</Info>

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é en tant que **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 pour le répartiteur de charge

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

  Cette exigence découle des composants suivants :

  * La fonctionnalité d'édition en temps réel de Server Pro utilise des WebSockets avec un repli sur le polling XHR. Chaque session d'édition possède 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 le [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) de Redis pour partager les mises à jour entre plusieurs instances Server Pro.
  * La compilation LaTeX conserve localement le résultat et le cache de compilation pour optimiser les performances. Après l'envoi d'une requête de compilation à une instance Server Pro, les requêtes de téléchargement du PDF/du journal qui suivent doivent être routées vers la même instance Server Pro.
* **Délais d'expiration des requêtes longs** pour permettre la compilation de documents LaTeX volumineux
* **Prise en charge des WebSockets** pour des performances optimales
* **Taille de charge utile POST de 50 Mo**
* Le **délai keep-alive** doit être inférieur au délai keep-alive de Server Pro

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

  Avec la valeur par défaut, un délai keep-alive de 60 s dans le répartiteur de charge fonctionne.

  Avec `NGINX_KEEPALIVE_TIMEOUT=120`, le répartiteur de charge pourrait utiliser 115 s.
* **Adresses IP des clients**

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

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

<Accordion title="Exemple de configuration HAProxy">
  ```text theme={null}
  global
    group haproxy
    user haproxy

    # Verbose logging
    log stdout format raw local0 debug

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

    # Verbose logging
    log                     global
    option                  httplog

    # Reroute to a different backend if the sticky one is down
    option                  redispatch 1
    # These retries are for TCP connect errors, not on HTTP status 500 responses
    retries                 3

    # Sticky session for 24h of inactivity -- compile output is deleted after 24h
    cookie                  server-pro-ha insert maxidle 24h

    # Try to connect to any backend for 1min, then return 503
    timeout queue           1m
    # Give Server Pro instances 15s to startup
    timeout connect         15s

    # Abort requests from very slow clients (allow 1min of inactivity when reading a request)
    timeout client          1m

    # Allow slow compiles -- hard-coded limit in clsi is 10min
    timeout server          10m

    # Disconnect the editor after 23h -- 1h ahead of their last use yesterday
    timeout tunnel          23h

    # Note: The keepalive behavior in haproxy works great with the default keepalive setup in Server Pro.
    #       Haproxy is cleaning up connections in the background and it will redispatch requests when needed.

  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

    # Tell the application that we are behind https
    http-request set-header X-Forwarded-Proto https

    # Tell the application the actual client ip
    option forwardfor

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

    # Route git traffic to the sibling container of the git-bridge
    use-server server-pro-ha-1 if { path_beg /git/ }

    # Debugging
    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
  ```
</Accordion>

#### Configuration de Server Pro

**Secrets**

Les instances Server Pro doivent partager les mêmes secrets :

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

Chacun de ces secrets doit être configuré avec sa propre valeur unique et partagé entre les instances.

S'ils ne sont pas configurés et que les requêtes d'un utilisateur sont routées vers différentes instances Server Pro, ses requêtes échoueront aux vérifications d'authentification : il sera soit fréquemment redirigé vers la page de connexion, soit ses actions dans l'interface échoueront de manière inattendue.

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

```bash wrap theme={null}
# 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+/'
```

**MongoDB**

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

**Redis**

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

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

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

**Fichiers éphémères**

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

<Danger>
  Nous vous 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.
</Danger>

**Configuration du proxy**

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

**Intégration de Git-bridge**

<Info>
  Git-bridge est disponible dans Server Pro à partir de la version 4.0.1.
</Info>

Le conteneur git-bridge a besoin d'un conteneur Server Pro voisin (sibling) pour traiter les requêtes git entrantes. Ce conteneur voisin peut également servir le trafic utilisateur habituel. Dans l'exemple de configuration, la première instance joue le rôle de conteneur voisin pour git-bridge, mais n'importe quelle instance pourrait en réalité remplir ce rôle.

Pourquoi faut-il désigner un conteneur Server Pro comme voisin de git-bridge ? Server Pro fournit à git-bridge des URL de téléchargement pour le service d'historique. Ces URL d'historique doivent être configurées pour être accessibles depuis le conteneur git-bridge.

Configuration du conteneur Server Pro :

* Définissez `GIT_BRIDGE_ENABLED` sur `'true'`
* Définissez `GIT_BRIDGE_HOST` sur `<git-bridge container name>`, par exemple `git-bridge`
* Définissez `GIT_BRIDGE_PORT` sur `8000`
* Définissez `V1_HISTORY_URL` sur `http://<server-pro sibling container name>:3100/api`.

  Remarque : ceci n'est nécessaire que sur le conteneur voisin 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` sur `http://<server-pro sibling container name>/api/v0`, par exemple `http://server-pro-ha-1/api/v0`
* Définissez `GIT_BRIDGE_OAUTH2_SERVER` sur `http://<server-pro sibling container name>`, par exemple `http://server-pro-ha-1`
* Définissez `GIT_BRIDGE_POSTBACK_BASE_URL` sur `http://<git-bridge container name>:8000`, par exemple `http://git-bridge:8000`
* Définissez `GIT_BRIDGE_ROOT_DIR` sur le disque de données git-bridge monté, par exemple `/data/git-bridge`

<Accordion title="Exemple de configuration docker-compose.yml">
  La configuration suivante présente une installation autonome. Pour que la démo fonctionne, vous devez fournir une clé et un certificat SSL valides et ajuster `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é dans les commentaires. Pour une installation réelle, vous devez également déplacer chaque conteneur sur des nœuds dédiés et adapter les adresses IP à la configuration de votre réseau local.

  ```yaml theme={null}
  version: '2.2'

  # Actual horizontal scaling setup: pick your own network and replace IPs in config.
  networks:
      default:
          ipam:
              config:
                  # This subnet is part of a reserved subnet used for benchmarking
                  # https://tools.ietf.org/html/rfc2544
                  # The full subnet is 198.18.0.0/15
                  # Use 198.18.0.0/24 for lb and dbs
                  # Use 198.18.1.0/24 for server-pro
                  # Use 198.18.0.128/25 for ephemeral container
                  - gateway: 198.18.0.1
                    ip_range: 198.18.0.128/25
                    subnet: 198.18.0.0/23

  services:
      # Actual horizontal scaling setup: run haproxy outside docker on a separate host.
      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 to "ports": use host network to avoid docker-proxy overhead
          network_mode: host

          # Alternative to "network_mode: host": use docker-proxy for network isolation
          # ports:
          #     - "80:80"
          #     - "443:443"
          # networks:
          #     default:
          #         ipv4_address: 198.18.0.2

          # Actual horizontal scaling setup: remove these as they run on other hosts.
          depends_on:
              server-pro-ha-1:
                  condition: service_started
              server-pro-ha-2:
                  condition: service_started
              server-pro-ha-3:
                  condition: service_started

      # Actual horizontal scaling setup: run this container next to server-pro-ha-1.
      # For Server Pro 4.0 onwards.
      git-bridge:
          restart: always
          # The tag should match the `server-pro-ha-1` container tag.
          image: quay.io/sharelatex/git-bridge:4.0.1
          volumes:
              # Actual horizontal scaling setup: point /data/git-bridge at a dedicated local ssd.
              - ~/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"]

          # Actual horizontal scaling setup: run on host 198.18.0.6 and expose port
          # ports:
          #     - "8000:8000"
          networks:
              default:
                  ipv4_address: 198.18.0.6

      # Actual horizontal scaling setup: run this container on a separate host.
      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:
              # Actual horizontal scaling setup: keep this entry.
              git-bridge:
                  condition: service_started

              # Actual horizontal scaling setup: remove the ones below as they run on other hosts.
              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
              # Actual horizontal scaling setup: provide your own domain/app name.
              OVERLEAF_SITE_URL: 'https://overleaf.example.com'
              OVERLEAF_APP_NAME: Server Pro Horizontal Scaling Demo

              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
              # Actual horizontal scaling setup: pick secure credentials.
              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
              # Only needed on the sibling instance of git-bridge
              V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
              # /git-bridge

              # Horizontal scaling
              # Actual horizontal scaling setup: pick secure credentials.
              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'
              # Actual horizontal scaling setup: IPs of load balancers
              TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
              # /Horizontal scaling

          # Actual horizontal scaling setup: run on host 198.18.1.1 and expose ports
          # ports:
          #     - "80:80"
          networks:
              default:
                  ipv4_address: 198.18.1.1

      # Actual horizontal scaling setup: run this container on a separate host.
      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"

          # Actual horizontal scaling setup: run on host 198.18.1.2 and expose ports
          # ports:
          #     - "80:80"
          networks:
              default:
                  ipv4_address: 198.18.1.2

      # Actual horizontal scaling setup: run this container on a separate host.
      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"

          # Actual horizontal scaling setup: run on host 198.18.1.3 and expose ports
          # ports:
          #     - "80:80"
          networks:
              default:
                  ipv4_address: 198.18.1.3

      # Actual horizontal scaling setup: run this container on a separate host.
      minio:
          image: minio/minio:RELEASE.2023-05-18T00-05-36Z
          container_name: minio
          command: server /data
          volumes:
              # Actual horizontal scaling setup: run minio with multiple disks, see minio docs.
              - ~/minio_data:/data
          environment:
              # Actual horizontal scaling setup: pick secure credentials.
              MINIO_ROOT_USER: MINIO_ROOT_USER
              MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

          # Actual horizontal scaling setup: run on host 198.18.0.5 and expose port
          # ports:
          #     - "9000:9000"
          networks:
              default:
                  ipv4_address: 198.18.0.5

      # Actual horizontal scaling setup: run this setup once on a separate host.
      minio_setup:
          depends_on:
              - minio
          image: minio/mc:RELEASE.2023-05-18T16-59-00Z
          entrypoint: sh
          command:
              - '-c'
              # Actual horizontal scaling setup: pick secure credentials.
              - |
                  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

                  # Put the contents of the policy from the previous section in policy-filestore.json
                  # Reminder: Replace the bucket names accordingly.
                  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

      # Actual horizontal scaling setup: run this container on a separate host.
      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

          # Actual horizontal scaling setup: run on host 198.18.0.3 and expose 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
          command:
              - '-c'
              - |
                  mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

      # Actual horizontal scaling setup: run this container on a separate host.
      redis:
          restart: always
          image: redis:6.2
          container_name: redis
          expose:
              - 6379
          volumes:
              - ~/redis_data:/data

          # Actual horizontal scaling setup: run on host 198.18.0.4 and expose port
          # ports:
          #     - "6379:6379"
          networks:
              default:
                  ipv4_address: 198.18.0.4
  ```
</Accordion>

#### 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 sur les [spécifications matérielles](/fr/on-premises/getting-started/requirements/hardware-requirements) des instances Server Pro s'appliquent.

#### Mettre à niveau Server Pro

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

Les migrations doivent être terminées avant le démarrage de l'application web proprement dite. Vous pouvez soit rechercher l'entrée `Finished migrations` dans les journaux, soit attendre que l'application accepte du trafic.

La procédure de mise à niveau se déroule comme suit :

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 la [documentation](/fr/on-premises/maintenance/data-and-backups#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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.