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

# scalabilità orizzontale

A partire dalla versione 3.5.6, Server Pro supporta lo scaling 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 abbiano il prefisso corretto (ad es. `SHARELATEX_SITE_URL` invece di `OVERLEAF_SITE_URL`)
{% endhint %}

Configurare lo scaling orizzontale richiede un notevole impegno. Consigliamo di prendere in considerazione lo scaling orizzontale **solo** quando si raggiunge una certa scala. Per 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 [requisiti hardware](/on-premises/it/per-iniziare/requirements/hardware-requirements.md) documentazione per i consigli.

Una distribuzione di Server Pro con scaling orizzontale comporta un insieme di componenti esterni, come un bilanciatore del carico e un backend di archiviazione compatibile con S3.

Possiamo aiutare 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 nella 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 persistita 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 opera 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 distribuire Server Pro con database compatibili **potrebbe** essere possibile, supportiamo ufficialmente solo distribuzioni che utilizzano MongoDB.<br>
* **Redis**

  * Redis memorizza i dati temporanei, come gli aggiornamenti dei documenti in sospeso prima che vengano scritti su MongoDB.
  * Redis viene utilizzato per comunicare gli aggiornamenti dei documenti tra servizi diversi e per notificare all'editor i cambiamenti di stato in un dato progetto.
  * Redis viene utilizzato per memorizzare le sessioni degli utenti.
  * 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 distribuire Server Pro con archivi compatibili **potrebbe** essere possibile, supportiamo ufficialmente solo distribuzioni che utilizzano Redis.<br>
* **File di progetto e file di cronologia**

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

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

  **Importante:** NFS/Amazon EFS/Amazon EBS sono **non** supportati per lo scaling orizzontale. Consulta la [archiviazione hardware](/on-premises/it/per-iniziare/requirements/hardware-requirements.md#storage) sezione dei requisiti sullo scaling dell'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 persistito né sottoposto a backup.
  * Anche il buffering dei nuovi upload di file e la creazione di file zip del progetto traggono vantaggio dall'uso di un disco locale.

{% hint style="danger" %}
Consigliamo vivamente di usare un disco locale. L'uso di qualsiasi tipo di disco in 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 archiviati 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 regolare.

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

* un'istanza centralizzata di MongoDB accessibile da tutte le istanze di Server Pro
* un'istanza centralizzata di Redis accessibile da tutte le istanze di Server Pro
* un backend di archiviazione centralizzato 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 contenitore git-bridge per i dati di git-bridge

#### Requisiti del bilanciatore del carico

* **Instradamento persistente**, ad esempio usando un cookie

  Questo requisito deriva da questi componenti:

  * La funzionalità di editing in tempo reale in Server Pro usa WebSocket con fallback al 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 indirizzate 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 l'output e la cache di compilazione localmente per prestazioni ottimali. Una volta inviata una richiesta di compilazione a una istanza di Server Pro, le seguenti richieste di download del PDF/log devono essere indirizzate alla stessa istanza di Server Pro.
* **Timeout delle richieste lunghi** per supportare la compilazione di documenti LaTeX di grandi dimensioni
* **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, un timeout keep-alive di 60 s nel bilanciatore del carico funziona.

  Con `NGINX_KEEPALIVE_TIMEOUT=120`, il bilanciatore del carico potrebbe impostare 115 s.
* **IP client**

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

  Il bilanciatore del carico deve aggiungere l'intestazione della richiesta `X-Forwarded-Proto: https`.

<details>

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

```
global
  group haproxy
  user haproxy

  # Log dettagliato
  log stdout format raw local0 debug

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

  # Log dettagliato
  log                     global
  option                  httplog

  # Reindirizza a un backend diverso se quello sticky è inattivo
  option                  redispatch 1
  # Questi tentativi di ripetizione servono per errori di connessione TCP, non per risposte HTTP con stato 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 alle istanze di Server Pro 15 s per avviarsi
  timeout connect         15s

  # Interrompi le richieste dei 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 dopo il loro ultimo utilizzo di ieri
  timeout tunnel          23h

  # Nota: il comportamento keepalive in haproxy funziona perfettamente con la configurazione keepalive predefinita in Server Pro.
  # Haproxy sta ripulendo le connessioni in background e reindirizzerà 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 il vero IP 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 contenitore fratello 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 concordare segreti condivisi:

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

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

Quando non sono configurati e le richieste degli utenti vengono indirizzate a istanze diverse di Server Pro, le loro richieste falliranno i controlli di autenticazione e verranno frequentemente reindirizzati alla pagina di accesso oppure le loro azioni nell'interfaccia utente falliranno in modi inaspettati.

Quando non sono configurati, Server Pro usa un nuovo valore casuale per ogni segreto basato su 32 byte casuali 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**

Imposta `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` per le versioni `4.x` e precedenti) sull'istanza centralizzata di MongoDB.

**Redis**

Imposta `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` per le versioni `4.x` e precedenti) e `REDIS_HOST` sull'istanza centralizzata di Redis.

**Archiviazione compatibile con S3 per i file di progetto e della 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 in 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 ottenere IP client accurati.
* Imposta `TRUSTED_PROXY_IPS` all'IP del bilanciatore del carico (si possono 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 contenitore git-bridge ha bisogno di un contenitore fratello di Server Pro per gestire le richieste git in arrivo. Questo contenitore fratello può servire anche il traffico normale degli utenti. Nella configurazione di esempio, la prima istanza funge da contenitore fratello per git-bridge, ma in realtà qualsiasi istanza potrebbe svolgere quel ruolo.

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

Configurazione del contenitore Server Pro:

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

  Nota: questo è necessario solo sul contenitore fratello per il contenitore git-bridge. Le altre istanze possono usare un URL localhost, che è l'impostazione predefinita.

Configurazione del contenitore git-bridge:

* Imposta `GIT_BRIDGE_API_BASE_URL` a `http://<nome del contenitore fratello di server-pro>/api/v0`, ad esempio `http://server-pro-ha-1/api/v0`
* Imposta `GIT_BRIDGE_OAUTH2_SERVER` a `http://<nome del contenitore fratello di server-pro>`, ad esempio `http://server-pro-ha-1`
* Imposta `GIT_BRIDGE_POSTBACK_BASE_URL` a `http://<nome del contenitore git-bridge>:8000`, ad esempio `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 un setup autonomo. Per far funzionare la demo, devi fornire una chiave/certificato SSL validi 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 in linea. Per una configurazione reale, devi spostare i singoli container su nodi dedicati e adattare gli indirizzi IP alla configurazione della tua rete locale.

```yaml
version: '2.2'

# Configurazione reale di scaling orizzontale: scegli la tua rete e sostituisci gli IP nella configurazione.
networks:
    default:
        ipam:
            config:
                # Questa subnet fa parte di una subnet riservata usata per il benchmarking
                # https://tools.ietf.org/html/rfc2544
                # L'intera subnet è 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 contenitore effimero
                - gateway: 198.18.0.1
                  ip_range: 198.18.0.128/25
                  subnet: 198.18.0.0/23

servizi:
    # Configurazione reale di scaling 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'
        volumi:
            - ./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
        # ports:
        #     - "80:80"
        #     - "443:443"
        # networks:
        #     default:
        #         ipv4_address: 198.18.0.2

        # Configurazione reale di scaling orizzontale: rimuovi questi elementi 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 di scaling orizzontale: esegui questo contenitore accanto a server-pro-ha-1.
    # Da Server Pro 4.0 in poi.
    git-bridge:
        restart: always
        # Il tag dovrebbe corrispondere al tag del contenitore `server-pro-ha-1`.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumi:
            # Configurazione reale di scaling orizzontale: punta /data/git-bridge a un SSD locale dedicato.
            - ~/git_bridge_data:/data/git-bridge
        container_name: git-bridge
        ambiente:
            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 di scaling orizzontale: esegui su host 198.18.0.6 ed esponi la porta
        # ports:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Configurazione reale di scaling orizzontale: esegui questo contenitore 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 di scaling orizzontale: mantieni questa voce.
            git-bridge:
                condition: service_started

            # Configurazione reale di scaling 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
        volumi:
            - /tmp/scratch-disk1:/var/lib/sharelatex
            - /var/run/docker.sock:/var/run/docker.sock
        environment: &server-pro-ha-environment
            # Configurazione reale di scaling orizzontale: fornisci un tuo dominio/nome app.
            OVERLEAF_SITE_URL: 'https://overleaf.example.com'
            OVERLEAF_APP_NAME: Demo di scaling 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 di scaling 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 di scaling 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 reale della scalabilità orizzontale: IP dei bilanciatori del carico
            TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
            # /Scalabilità orizzontale

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

    # Configurazione reale di scaling orizzontale: esegui questo contenitore su un host separato.
    server-pro-ha-2:
        <<: *server-pro-ha-config
        hostname: server-pro-ha-2
        container_name: server-pro-ha-2
        volumi:
            - /tmp/scratch-disk2:/var/lib/sharelatex
            - /var/run/docker.sock:/var/run/docker.sock
        ambiente:
            <<: *server-pro-ha-environment
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk2/data/compiles'
            V1_HISTORY_URL: "http://localhost:3100/api"

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

    # Configurazione reale di scaling orizzontale: esegui questo contenitore su un host separato.
    server-pro-ha-3:
        <<: *server-pro-ha-config
        hostname: server-pro-ha-3
        container_name: server-pro-ha-3
        volumi:
            - /tmp/scratch-disk3:/var/lib/sharelatex
            - /var/run/docker.sock:/var/run/docker.sock
        ambiente:
            <<: *server-pro-ha-environment
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk3/data/compiles'
            V1_HISTORY_URL: "http://localhost:3100/api"

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

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

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

    # Configurazione reale 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 di scaling 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

                # Inserire il contenuto della policy della sezione precedente in policy-filestore.json
                # Promemoria: sostituire 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 di scaling orizzontale: esegui questo contenitore su un host separato.
    mongo:
        restart: always
        image: mongo:4.4
        container_name: mongo
        command: "--replSet overleaf"
        expose:
            - 27017
        volumi:
            - ~/mongo_data:/data/db
        healthcheck:
            test: echo 'db.stats().ok' | mongo localhost:27017/test --quiet
            interval: 10s
            timeout: 10s
            retries: 5

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

    # Configurazione reale di scaling orizzontale: esegui questo contenitore su un host separato.
    redis:
        restart: always
        image: redis:6.2
        container_name: redis
        expose:
            - 6379
        volumi:
            - ~/redis_data:/data

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

</details>

#### Hardware

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

Le raccomandazioni generali su [le 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 **non** sono progettate per essere eseguite da più istanze in parallelo.

Le migrazioni devono terminare prima che l'applicazione web effettiva venga avviata. Puoi controllare i log per una voce di `Migrazioni completate` oppure attendere finché l'applicazione accetta il traffico.

La procedura di aggiornamento è la seguente:

1. Pianificare una finestra di manutenzione
2. Arrestare tutte le istanze di Server Pro
3. Eseguire un backup coerente come descritto in [documentazione](/on-premises/it/manutenzione/data-and-backups.md#performing-a-consistent-backup)
4. Avviare una singola istanza di Server Pro con la nuova versione
5. Verificare che la nuova istanza funzioni come previsto
6. Avviare 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://overleaf-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.