> 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/it/manutenzione/horizontal-scaling.md).

# Scalabilità orizzontale

A partire dalla versione 3.5.6, Server Pro supporta il ridimensionamento orizzontale.

Questo documento elenca i requisiti tecnici e fornisce linee guida per eseguire Server Pro su più nodi.

{% hint style="danger" %}
A partire da Server CE/Server Pro `5.0.3` le variabili d'ambiente sono state rinominate da `SHARELATEX_*` a `OVERLEAF_*`.

Se stai usando una `4.x` versione (o precedente), assicurati che le variabili siano prefissate di conseguenza (ad es. `SHARELATEX_SITE_URL` invece di `OVERLEAF_SITE_URL`)
{% endhint %}

La configurazione del ridimensionamento orizzontale richiede un notevole impegno. Consigliamo di prendere in considerazione il ridimensionamento orizzontale **solo** quando si raggiunge una certa scala. Ad esempio, un'installazione di Server Pro per 1.000 utenti totali è stata configurata con successo usando un singolo server dotato di due processori a 4 core e 32 GB di memoria di sistema. Consulta la documentazione sui [requisiti hardware](/on-premises/it/per-iniziare/requirements/hardware-requirements.md) per le raccomandazioni.

Una distribuzione di Server Pro con ridimensionamento orizzontale prevede un insieme di componenti esterni, come un load balancer e un backend di archiviazione compatibile con S3.

Possiamo aiutarti a risolvere errori nei container di Server Pro che potrebbero essere il risultato di una configurazione errata e fornire consigli generali basati su questo documento. Purtroppo, non siamo in grado di fornire assistenza per la configurazione di applicazioni/sistemi di terze parti.

La risoluzione di problemi tecnici specifici del tuo hardware/software per fornire i componenti esterni non è coperta dai nostri termini di supporto.

### Requisiti

#### Archiviazione dati esterna e centralizzata

L'archiviazione dei dati in Server Pro può essere suddivisa in quattro archivi dati:

* **MongoDB**

  * La maggior parte dei dati viene mantenuta in MongoDB.
  * Supportiamo sia un'istanza locale sia un'istanza esterna, come [MongoDB](https://www.mongodb.com/atlas) Atlas (un servizio MongoDB completamente gestito che gira all'interno dell'infrastruttura AWS).<br>

  **Nota:** Purtroppo, al momento non esiste un supporto ufficiale per database compatibili con MongoDB come CosmoDB/DocumentDB, poiché non abbiamo testato Server Pro con essi. Sebbene l'implementazione di Server Pro con database compatibili **possa** essere possibile, supportiamo ufficialmente solo distribuzioni che usano MongoDB.<br>
* **Redis**

  * Redis memorizza dati temporanei, come gli aggiornamenti di documenti in sospeso prima che vengano scritti su MongoDB.
  * Redis viene usato per comunicare gli aggiornamenti dei documenti tra servizi diversi e per notificare all'editor i cambiamenti di stato in un determinato progetto.
  * Redis viene usato per memorizzare le sessioni utente.
  * Supportiamo sia un'istanza locale sia un'istanza esterna.<br>

  **Nota:** Purtroppo, al momento non esiste un supporto ufficiale per archivi chiave/valore compatibili con Redis come KeyDB/Valkey, poiché non abbiamo testato Server Pro con essi. Sebbene l'implementazione di Server Pro con archivi compatibili **possa** sia possibile, supportiamo ufficialmente solo distribuzioni che usano Redis.<br>
* **File di progetto e file di cronologia**

  * I file di progetto non modificabili sono memorizzati al di fuori di MongoDB.

    Il nuovo sistema di cronologia dei progetti (Server Pro 3.5 in poi) memorizza la cronologia anch'essa al di fuori di MongoDB.
  * Per le piccole istanze singole supportiamo sia un file system locale (che potrebbe essere supportato da un SSD locale, NFS o EBS) sia un [sistema di archiviazione dati compatibile con S3](/on-premises/it/configurazione/overleaf-toolkit/s3.md).
  * Per il ridimensionamento orizzontale, **solo** supportiamo sistemi di archiviazione dati compatibili con S3.<br>

  **Importante:** NFS/Amazon EFS/Amazon EBS sono **non** supportati per il ridimensionamento orizzontale. Consulta la [memorizzazione hardware](/on-premises/it/per-iniziare/requirements/hardware-requirements.md#storage) sezione requisiti per il ridimensionamento dello spazio di archiviazione in Server Pro per maggiori dettagli.
* **File effimeri**
  * Le compilazioni LaTeX devono essere eseguite su dischi locali veloci per prestazioni ottimali. L'output della compilazione non deve essere mantenuto o sottoposto a backup.
  * Anche il buffering dei nuovi caricamenti di file e la creazione di file zip dei progetti trae vantaggio dall'uso di un disco locale.

{% hint style="danger" %}
Sconsigliamo vivamente l'uso di un disco locale. L'uso di qualsiasi tipo di disco di rete (come NFS o EBS) può causare errori di compilazione imprevisti e altri problemi di prestazioni.
{% endhint %}

#### **Git-bridge**

{% hint style="info" %}
Git-bridge è disponibile in Server Pro a partire dalla versione 4.0.1.
{% endhint %}

I repository git sono memorizzati localmente su disco. Non sono disponibili opzioni di replica. Git-bridge dovrebbe essere eseguito come un **singleton**. Per prestazioni ottimali, consigliamo di usare un disco locale per i dati di git-bridge. Il disco dati di git-bridge dovrebbe essere sottoposto a backup regolarmente.

Per l'archiviazione dei dati con ridimensionamento orizzontale, ti servono:

* un'istanza centrale MongoDB accessibile da tutte le istanze di Server Pro
* un'istanza centrale Redis accessibile da tutte le istanze di Server Pro
* un backend di archiviazione centrale compatibile con S3 per i file di progetto e di cronologia
* un disco locale su ogni istanza per i file effimeri
* un disco locale sull'istanza che ospita il container git-bridge per i dati di git-bridge

#### Requisiti del load balancer

* **Instradamento persistente**, ad es. usando un cookie

  Questo requisito deriva da questi componenti:

  * La funzionalità di editing in tempo reale in Server Pro usa WebSocket con fallback a polling XHR. Ogni sessione di editing ha uno stato locale sul lato server e le richieste di una data sessione di editing devono sempre essere instradate alla stessa istanza di Server Pro. La funzionalità di collaborazione usa Redis [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) per condividere gli aggiornamenti tra più istanze di Server Pro.
  * La compilazione LaTeX mantiene localmente l'output e la cache di compilazione per prestazioni ottimali. Quando si invia una richiesta di compilazione a una istanza di Server Pro, le successive richieste di download del PDF/log devono essere instradate alla stessa istanza di Server Pro.
* **Timeout lunghi delle richieste** per supportare la compilazione di grandi documenti LaTeX
* **Supporto WebSocket** per prestazioni ottimali
* **dimensione del payload POST di 50 MB**
* **Timeout keep-alive** deve essere inferiore al timeout keep-alive di Server Pro

  Il timeout keep-alive in Server Pro può essere configurato usando la variabile d'ambiente `NGINX_KEEPALIVE_TIMEOUT`. Il valore predefinito è 65 s.

  Con l'impostazione predefinita, funziona un timeout keep-alive di 60 s nel load balancer.

  Con `NGINX_KEEPALIVE_TIMEOUT=120`, il load balancer potrebbe impostare 115 s.
* **IP dei client**

  Imposta l'intestazione della richiesta `X-Forwarded-For` all'IP del client.
* Quando **terminazione SSL**

  Il load balancer deve aggiungere l'intestazione della richiesta `X-Forwarded-Proto: https`.

<details>

<summary>Configurazione di esempio di HAProxy</summary>

```
global
  group haproxy
  user haproxy

  # Logging dettagliato
  log stdout format raw local0 debug

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

  # Logging dettagliato
  log                     global
  option                  httplog

  # Reindirizza a un backend diverso se quello persistente non è disponibile
  option                  redispatch 1
  # Questi tentativi riguardano errori di connessione TCP, non risposte con stato HTTP 500
  retries                 3

  # Sessione sticky per 24 ore di inattività -- l'output della compilazione viene eliminato dopo 24 ore
  cookie                  server-pro-ha insert maxidle 24h

  # Prova a connetterti a qualsiasi backend per 1 min, poi restituisci 503
  timeout queue           1m
  # Concedi 15 s alle istanze di Server Pro per avviarsi
  timeout connect         15s

  # Interrompi le richieste provenienti da client molto lenti (consenti 1 min di inattività durante la lettura di una richiesta)
  timeout client          1m

  # Consenti compilazioni lente -- il limite codificato in clsi è 10 min
  timeout server          10m

  # Disconnetti l'editor dopo 23 ore -- 1 ora oltre l'ultimo utilizzo di ieri
  timeout tunnel          23h

  # Nota: il comportamento keepalive in haproxy funziona benissimo con la configurazione keepalive predefinita in Server Pro.
  #       Haproxy sta ripulendo le connessioni in background e reindirizzerà di nuovo le richieste quando necessario.

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

  # Indica all'applicazione che siamo dietro HTTPS
  http-request set-header X-Forwarded-Proto https

  # Indica all'applicazione l'IP reale del client
  option forwardfor

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

  # Instrada il traffico git al container sibling di git-bridge
  use-server server-pro-ha-1 if { path_beg /git/ }

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

#### Configurazione di Server Pro

**Segreti**

Le istanze di Server Pro devono condividere gli stessi segreti:

* `WEB_API_PASSWORD` (autenticazione API web)
* `STAGING_PASSWORD` e `V1_HISTORY_PASSWORD` stesso valore (autenticazione della cronologia)
* `CRYPTO_RANDOM` (per il cookie di sessione)
* `OT_JWT_AUTH_KEY` (autenticazione della cronologia)

Tutti questi segreti devono essere configurati con il proprio valore univoco e condivisi tra le istanze.

Se non vengono configurati e le richieste degli utenti vengono instradate a istanze diverse di Server Pro, la loro richiesta non supererà i controlli di autenticazione e verranno spesso reindirizzati alla pagina di accesso oppure le loro azioni nell'interfaccia falliranno in modi imprevisti.

Se non viene configurato, Server Pro usa un nuovo valore casuale per ogni segreto basato su 32 byte casuali provenienti da `/dev/urandom` (256 bit casuali).

{% 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**

Punta `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` per le versioni `4.x` e precedenti) all'istanza centrale di MongoDB.

**Redis**

Punta `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` per le versioni `4.x` e precedenti) e `REDIS_HOST` all'istanza centrale di Redis.

**Archiviazione compatibile con S3 per i file di progetto e di cronologia**

Consulta la documentazione su [archiviazione compatibile con S3](/on-premises/it/configurazione/overleaf-toolkit/s3.md) per i dettagli.

**File effimeri**

Il bind-mount predefinito di un SSD locale su `/var/lib/overleaf` (`/var/lib/sharelatex` per le versioni `4.x` e precedenti) sarà sufficiente. Assicurati di puntare `SANDBOXED_COMPILES_HOST_DIR` al punto di mount sull'host.

{% hint style="danger" %}
Consigliamo vivamente di usare un disco locale. L'uso di qualsiasi tipo di disco di rete (come NFS o EBS) può causare errori di compilazione imprevisti e altri problemi di prestazioni.
{% endhint %}

**Configurazione del proxy**

* Imposta `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` per le versioni `4.x` e precedenti) per IP client corretti.
* Imposta `TRUSTED_PROXY_IPS` all'IP del load balancer (è possibile specificare più CIDR, separati da una virgola).

**Integrazione di Git-bridge**

{% hint style="info" %}
Git-bridge è disponibile in Server Pro a partire dalla versione 4.0.1.
{% endhint %}

Il container git-bridge necessita di un container sibling di Server Pro per gestire le richieste git in entrata. Questo container sibling può servire anche il traffico normale degli utenti. Nella configurazione di esempio, la prima istanza funge da container sibling per git-bridge, ma in realtà qualsiasi istanza potrebbe svolgere questo ruolo.

Perché dobbiamo designare un container Server Pro come sibling di git-bridge? Server Pro fornisce a git-bridge gli URL di download per il servizio cronologia. Dobbiamo configurare questi URL della cronologia in modo che siano accessibili dal container git-bridge.

Configurazione del container Server Pro:

* Imposta `GIT_BRIDGE_ENABLED` a `'true'`
* Imposta `GIT_BRIDGE_HOST` a `<nome container git-bridge>` ad es. `git-bridge`
* Imposta `GIT_BRIDGE_PORT` a `8000`
* Imposta `V1_HISTORY_URL` a `http://<nome container sibling server-pro>:3100/api`.

  Nota: questo è necessario solo sul container sibling per il container git-bridge. Le altre istanze possono usare un URL localhost, che è il valore predefinito.

Configurazione del container git-bridge:

* Imposta `GIT_BRIDGE_API_BASE_URL` a `http://<nome container sibling server-pro>/api/v0`, ad es. `http://server-pro-ha-1/api/v0`
* Imposta `GIT_BRIDGE_OAUTH2_SERVER` a `http://<nome container sibling server-pro>`, ad es. `http://server-pro-ha-1`
* Imposta `GIT_BRIDGE_POSTBACK_BASE_URL` a `http://<nome container git-bridge>:8000`, ad es. `http://git-bridge:8000`
* Imposta `GIT_BRIDGE_ROOT_DIR` al disco dati di git-bridge montato tramite bind, ad es. `/data/git-bridge`

<details>

<summary>Configurazione di esempio di docker-compose.yml</summary>

La configurazione seguente mostra una configurazione autonoma. Per far funzionare la demo, devi fornire una chiave/certificato SSL valido e adattare il `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` per le versioni `4.x` e precedenti). Per una configurazione reale, devi sostituire i segreti fittizi con segreti reali come indicato inline. Per una configurazione reale, devi spostare i singoli container su nodi dedicati e adattare gli indirizzi IP alla tua configurazione di rete locale.

```yaml
version: '2.2'

# Configurazione reale del ridimensionamento orizzontale: scegli la tua rete e sostituisci gli IP nella configurazione.
networks:
    default:
        ipam:
            config:
                # Questa sottorete fa parte di una sottorete riservata usata per il benchmarking
                # https://tools.ietf.org/html/rfc2544
                # L'intera sottorete è 198.18.0.0/15
                # Usa 198.18.0.0/24 per lb e db
                # Usa 198.18.1.0/24 per server-pro
                # Usa 198.18.0.128/25 per il container effimero
                - gateway: 198.18.0.1
                  ip_range: 198.18.0.128/25
                  subnet: 198.18.0.0/23

services:
    # Configurazione reale del ridimensionamento orizzontale: esegui haproxy fuori da Docker su un host separato.
    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
        # Alternativa a "ports": usa la rete host per evitare l'overhead di docker-proxy
        network_mode: host

        # Alternativa a "network_mode: host": usa docker-proxy per l'isolamento di rete
        # porte:
        #     - "80:80"
        #     - "443:443"
        # reti:
        #     default:
        #         ipv4_address: 198.18.0.2

        # Configurazione reale del ridimensionamento orizzontale: rimuovili poiché vengono eseguiti su altri host.
        depends_on:
            server-pro-ha-1:
                condition: service_started
            server-pro-ha-2:
                condition: service_started
            server-pro-ha-3:
                condition: service_started

    # Configurazione reale del ridimensionamento orizzontale: esegui questo container accanto a server-pro-ha-1.
    # Per Server Pro 4.0 e successive.
    git-bridge:
        restart: always
        # Il tag dovrebbe corrispondere al tag del container `server-pro-ha-1`.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumes:
            # Configurazione reale del ridimensionamento orizzontale: punta /data/git-bridge a un SSD locale dedicato.
            - ~/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"]

        # Configurazione reale del ridimensionamento orizzontale: esegui su host 198.18.0.6 ed esponi la porta
        # porte:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Configurazione reale del ridimensionamento orizzontale: esegui questo container su un host separato.
    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:
            # Configurazione reale del ridimensionamento orizzontale: mantieni questa voce.
            git-bridge:
                condition: service_started

            # Configurazione reale del ridimensionamento orizzontale: rimuovi quelle sotto poiché vengono eseguite su altri host.
            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
            # Configurazione reale del ridimensionamento orizzontale: fornisci il tuo dominio/nome app.
            OVERLEAF_SITE_URL: 'https://overleaf.example.com'
            OVERLEAF_APP_NAME: Demo di ridimensionamento orizzontale di 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
            # Configurazione reale del ridimensionamento orizzontale: scegli credenziali sicure.
            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
            # Necessario solo sull'istanza gemella di git-bridge
            V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
            # /git-bridge

            # Scalabilità orizzontale
            # Configurazione reale del ridimensionamento orizzontale: scegli credenziali sicure.
            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'
            # Configurazione effettiva della scalabilità orizzontale: IP dei bilanciatori di carico
            TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
            # /Scalabilità orizzontale

        # Configurazione effettiva della scalabilità orizzontale: eseguire sull'host 198.18.1.1 ed esporre le porte
        # porte:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.1

    # Configurazione reale del ridimensionamento orizzontale: esegui questo container su un host separato.
    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"

        # Configurazione effettiva della scalabilità orizzontale: eseguire sull'host 198.18.1.2 ed esporre le porte
        # porte:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.2

    # Configurazione reale del ridimensionamento orizzontale: esegui questo container su un host separato.
    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"

        # Configurazione effettiva della scalabilità orizzontale: eseguire sull'host 198.18.1.3 ed esporre le porte
        # porte:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.3

    # Configurazione reale del ridimensionamento orizzontale: esegui questo container su un host separato.
    minio:
        image: minio/minio:RELEASE.2023-05-18T00-05-36Z
        container_name: minio
        command: server /data
        volumes:
            # Configurazione effettiva della scalabilità orizzontale: eseguire minio con più dischi, vedere la documentazione di minio.
            - ~/minio_data:/data
        environment:
            # Configurazione reale del ridimensionamento orizzontale: scegli credenziali sicure.
            MINIO_ROOT_USER: MINIO_ROOT_USER
            MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

        # Configurazione effettiva della scalabilità orizzontale: eseguire sull'host 198.18.0.5 ed esporre la porta
        # porte:
        #     - "9000:9000"
        networks:
            default:
                ipv4_address: 198.18.0.5

    # Configurazione effettiva della scalabilità orizzontale: eseguire questa configurazione una sola volta su un host separato.
    minio_setup:
        depends_on:
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        comando:
            - '-c'
            # Configurazione reale del ridimensionamento orizzontale: scegli credenziali sicure.
            - |
                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

                # Inserisci il contenuto della policy della sezione precedente in policy-filestore.json
                # Promemoria: sostituisci i nomi dei bucket di conseguenza.
                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

    # Configurazione reale del ridimensionamento orizzontale: esegui questo container su un host separato.
    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

        # Configurazione effettiva della scalabilità orizzontale: eseguire sull'host 198.18.0.3 ed esporre la porta
        # porte:
        #     - "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
        comando:
            - '-c'
            - |
                mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

    # Configurazione reale del ridimensionamento orizzontale: esegui questo container su un host separato.
    redis:
        restart: always
        image: redis:6.2
        container_name: redis
        expose:
            - 6379
        volumes:
            - ~/redis_data:/data

        # Configurazione effettiva della scalabilità orizzontale: eseguire sull'host 198.18.0.4 ed esporre la porta
        # porte:
        #     - "6379:6379"
        networks:
            default:
                ipv4_address: 198.18.0.4
```

</details>

#### Hardware

Consigliamo di utilizzare le stesse specifiche hardware per tutte le istanze di Server Pro che partecipano alla scalabilità orizzontale.

Le raccomandazioni generali sulle [specifiche hardware](/on-premises/it/per-iniziare/requirements/hardware-requirements.md) per le istanze di Server Pro si applicano.

#### Aggiornamento di Server Pro

Come parte del processo di aggiornamento, Server Pro esegue automaticamente le migrazioni del database. Queste migrazioni sono **non** progettate per essere eseguite da più istanze in parallelo.

Le migrazioni devono terminare prima dell'avvio della vera applicazione web. Puoi controllare nei log la presenza di una voce `Migrazioni completate` oppure attendere che l'applicazione accetti traffico.

La procedura di aggiornamento è la seguente:

1. Pianifica una finestra di manutenzione
2. Arresta tutte le istanze di Server Pro
3. Esegui un backup coerente come descritto in [documentazione](/on-premises/it/manutenzione/data-and-backups.md#performing-a-consistent-backup)
4. Avvia una singola istanza di Server Pro con la nuova versione
5. Verifica che la nuova istanza funzioni come previsto
6. Avvia le altre istanze con la nuova versione


---

# 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/it/manutenzione/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.