> 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/sv/underhall/horizontal-scaling.md).

# Horisontell skalning

Från och med version 3.5.6 stöder Server Pro horisontell skalning.

Det här dokumentet listar de tekniska kraven och ger riktlinjer för att köra Server Pro på mer än en nod.

{% hint style="danger" %}
Från och med Server CE/Server Pro `5.0.3` miljövariablerna har bytt namn från `SHARELATEX_*` till `OVERLEAF_*`.

Om du använder en `4.x` version (eller tidigare), se till att variablerna har rätt prefix (t.ex. `SHARELATEX_SITE_URL` i stället för `OVERLEAF_SITE_URL`)
{% endhint %}

Att sätta upp horisontell skalning kräver en betydande arbetsinsats. Vi rekommenderar att överväga horisontell skalning **endast** när en viss skala uppnås. Som exempel har en Server Pro-installation för totalt 1 000 användare satts upp framgångsrikt med en enda server utrustad med två 4-kärniga processorer och 32 GB systemminne. Se [hårdvarukrav](/on-premises/sv/kom-igang/requirements/hardware-requirements.md) dokumentationen för rekommendationer.

En driftsättning av Server Pro med horisontell skalning innebär en uppsättning externa komponenter, såsom en lastbalanserare och en S3-kompatibel lagringsbackend.

Vi kan hjälpa till att felsöka fel i Server Pro-containrarna som kan vara resultatet av felkonfiguration och ge allmänna råd baserat på detta dokument. Tyvärr kan vi inte ge hjälp med att konfigurera tredjepartsapplikationer/-system.

Att lösa tekniska problem som är specifika för din hårdvara/mjukvara för att tillhandahålla de externa komponenterna omfattas inte av våra supportvillkor.

### Krav

#### Extern, central datalagring

Datalagringen i Server Pro kan delas upp i fyra datalager:

* **MongoDB**

  * Det mesta av datan lagras i MongoDB.
  * Vi stödjer antingen en lokal instans eller en extern instans, såsom [MongoDB](https://www.mongodb.com/atlas) Atlas (en helt hanterad MongoDB-tjänst som körs inom AWS-infrastrukturen).<br>

  **Obs:** Tyvärr finns det för närvarande inget officiellt stöd för MongoDB-kompatibla databaser som CosmoDB/DocumentDB, eftersom vi inte har testat Server Pro med dem. Även om det kan **vara** möjligt att driftsätta Server Pro med kompatibla databaser, stödjer vi officiellt endast driftsättningar som använder MongoDB.<br>
* **Redis**

  * Redis lagrar tillfällig data, såsom väntande dokumentuppdateringar innan de skrivs till MongoDB.
  * Redis används för att kommunicera dokumentuppdateringar mellan olika tjänster och meddela redigeraren om tillståndsförändringar i ett visst projekt.
  * Redis används för att lagra användarsessionerna.
  * Vi stödjer antingen en lokal instans eller en extern instans.<br>

  **Obs:** Tyvärr finns det för närvarande inget officiellt stöd för Redis-kompatibla nyckel/värde-lager som KeyDB/Valkey, eftersom vi inte har testat Server Pro med dem. Även om det kan **vara** vara möjligt att driftsätta Server Pro med kompatibla lager, stödjer vi officiellt endast driftsättningar som använder Redis.<br>
* **Projektfiler och historikfiler**

  * Icke-redigerbara projektfiler lagras utanför MongoDB.

    Det nya systemet för projektets historik (Server Pro 3.5 och senare) lagrar även historiken utanför MongoDB.
  * För små enskilda instanser stödjer vi antingen ett lokalt filsystem (som kan backas av en lokal SSD, NFS eller EBS) eller en [S3-kompatibelt datalagringssystem](/on-premises/sv/konfiguration/overleaf-toolkit/s3.md).
  * För horisontell skalning, **endast** stöder vi S3-kompatibla datalagringssystem.<br>

  **Viktigt:** NFS/Amazon EFS/Amazon EBS är **inte** stödda för horisontell skalning. Se [avsnittet om hårdvarulagring](/on-premises/sv/kom-igang/requirements/hardware-requirements.md#storage) krav för skalning av lagring i Server Pro för mer information.
* **Tillfälliga filer**
  * LaTeX-kompileringar behöver köras på snabba, lokala diskar för optimal prestanda. Utdata från kompileringen behöver inte bevaras eller säkerhetskopieras.
  * Buffring av nya filuppladdningar och skapandet av projektets zip-filer gynnas också av att använda en lokal disk.

{% hint style="danger" %}
Vi rekommenderar starkt att använda en lokal disk. Att använda någon form av nätverksdisk (såsom NFS eller EBS) kan resultera i oväntade kompileringsfel och andra prestandaproblem.
{% endhint %}

#### **Git-bridge**

{% hint style="info" %}
Git-bridge finns tillgängligt i Server Pro från och med version 4.0.1.
{% endhint %}

Git-förvaren lagras lokalt på disk. Inga replikeringsalternativ finns tillgängliga. Git-bridge bör köras som en **singleton**. För optimal prestanda rekommenderar vi att använda en lokal disk för Git-bridge-data. Datadisken för Git-bridge bör säkerhetskopieras regelbundet.

För datalagringen med horisontell skalning behöver du:

* en central MongoDB-instans som är åtkomlig från alla Server Pro-instanser
* en central Redis-instans som är åtkomlig från alla Server Pro-instanser
* en central S3-kompatibel lagringsbackend för projekt- och historikfiler
* en lokal disk på varje instans för tillfälliga filer
* en lokal disk på instansen som hostar git-bridge-containern för git-bridge-data

#### Krav på lastbalanserare

* **Beständig routning**, t.ex. genom att använda en cookie

  Detta krav kommer av dessa komponenter:

  * Funktionen för redigering i realtid i Server Pro använder WebSockets med fallback till XHR-pollning. Varje redigeringssession har lokalt tillstånd på serversidan och förfrågningarna för en given redigeringssession måste alltid routas till samma Server Pro-instans. Samarbetesfunktionen använder Redis [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) för att dela uppdateringar mellan flera Server Pro-instanser.
  * LaTeX-kompileringen behåller utdata och kompilationscachen lokalt för optimal prestanda. När en kompileringsförfrågan skickas till en Server Pro-instans, måste de efterföljande nedladdningsförfrågningarna för PDF/logg routas till samma Server Pro-instans.
* **Långa förfrågnings-timeouts** för att stödja kompilering av stora LaTeX-dokument
* **Stöd för WebSocket** för optimal prestanda
* **POST-payloadstorlek på 50 MB**
* **Keep-alive-timeout** måste vara lägre än Server Pro:s keep-alive-timeout

  Keep-alive-timeout i Server Pro kan konfigureras med miljövariabeln `NGINX_KEEPALIVE_TIMEOUT`. Standardvärdet är 65 s.

  Med standardinställningen fungerar en keep-alive-timeout på 60 s i lastbalanseraren.

  Med `NGINX_KEEPALIVE_TIMEOUT=120`, kan lastbalanseraren välja 115 s.
* **Klient-IP-adresser**

  Sätt begäranhuvudet `X-Forwarded-For` till klientens IP-adress.
* När **SSL-avslutning**

  Lastbalanseraren behöver lägga till begäranhuvudet `X-Forwarded-Proto: https`.

<details>

<summary>Exempel på HAProxy-konfiguration</summary>

```
global
  group haproxy
  user haproxy

  # Utförlig loggning
  log stdout format raw local0 debug

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

  # Utförlig loggning
  log                     global
  option                  httplog

  # Omdirigera till en annan backend om den klibbiga instansen är nere
  option                  redispatch 1
  # Dessa omförsök gäller TCP-anslutningsfel, inte HTTP-status 500-svar
  retries                 3

  # Beständig session i 24 timmars inaktivitet -- kompilationsutdata raderas efter 24 h
  cookie                  server-pro-ha insert maxidle 24h

  # Försök att ansluta till vilken backend som helst i 1 min, returnera sedan 503
  timeout queue           1m
  # Ge Server Pro-instanserna 15 s att starta
  timeout connect         15s

  # Avbryt förfrågningar från mycket långsamma klienter (tillåt 1 min inaktivitet vid läsning av en förfrågan)
  timeout client          1m

  # Tillåt långsamma kompileringar -- hårdkodad gräns i clsi är 10 min
  timeout server          10m

  # Koppla bort redigeraren efter 23 h -- 1 h före deras senaste användning i går
  timeout tunnel          23h

  # Obs: keepalive-beteendet i haproxy fungerar utmärkt med standardinställningen för keepalive i Server Pro.
  #       Haproxy städar upp anslutningar i bakgrunden och omdirigerar förfrågningar vid behov.

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

  # Tala om för applikationen att vi är bakom https
  http-request set-header X-Forwarded-Proto https

  # Tala om för applikationen den faktiska klient-IP-adressen
  option forwardfor

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

  # Route git-trafik till syskoncontainern för git-bridge
  use-server server-pro-ha-1 if { path_beg /git/ }

  # Felsökning
  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>

#### Server Pro-konfiguration

**Hemligheter**

Server Pro-instanserna behöver komma överens om delade hemligheter:

* `WEB_API_PASSWORD` (auth för webb-API)
* `STAGING_PASSWORD` och `V1_HISTORY_PASSWORD` samma värde (autentisering för historik)
* `CRYPTO_RANDOM` (för sessionscookie)
* `OT_JWT_AUTH_KEY` (autentisering för historik)

Alla dessa hemligheter måste konfigureras med sina egna unika värden och delas mellan instanserna.

När de inte är konfigurerade och användarförfrågningar routas till olika Server Pro-instanser kommer deras förfrågningar att underkännas i autentiseringskontrollerna och de kommer antingen att omdirigeras till inloggningssidan ofta eller så kommer deras åtgärder i gränssnittet att misslyckas på oväntade sätt.

När de inte är konfigurerade använder Server Pro ett nytt slumpmässigt värde för varje hemlighet baserat på 32 slumpmässiga byte från `/dev/urandom` (256 slumpmässiga bitar).

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

Peka `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` för versioner `4.x` och tidigare) till den centrala MongoDB-instansen.

**Redis**

Peka `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` för versioner `4.x` och tidigare) och `REDIS_HOST` till den centrala Redis-instansen.

**S3-kompatibel lagring för projekt- och historikfiler**

Se dokumentationen om [S3-kompatibel lagring](/on-premises/sv/konfiguration/overleaf-toolkit/s3.md) för detaljer.

**Tillfälliga filer**

Standardmonteringen av en lokal SSD till `/var/lib/overleaf` (`/var/lib/sharelatex` för versioner `4.x` och tidigare) kommer att räcka. Se till att peka `SANDBOXED_COMPILES_HOST_DIR` till monteringspunkten på värden.

{% hint style="danger" %}
Vi rekommenderar starkt att använda en lokal disk. Att använda någon form av nätverksdisk (såsom NFS eller EBS) kan resultera i oväntade kompileringsfel och andra prestandaproblem.
{% endhint %}

**Proxykonfiguration**

* Ställ in `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` för versioner `4.x` och tidigare) för korrekta klient-IP-adresser.
* Ställ in `TRUSTED_PROXY_IPS` till lastbalanserarens IP-adress (flera CIDR:er kan anges, separerade med komma).

**Integration för Git-bridge**

{% hint style="info" %}
Git-bridge finns tillgängligt i Server Pro från och med version 4.0.1.
{% endhint %}

Git-bridge-containern behöver en syskon-Server Pro-container för att hantera inkommande git-förfrågningar. Denna syskoncontainer kan också betjäna vanlig användartrafik. I exempelkonfigurationen fungerar den första instansen som syskoncontainer för Git-bridge, men egentligen skulle vilken instans som helst kunna göra det.

Varför behöver vi utse en Server Pro-container som syskon till Git-bridge? Server Pro skickar nedladdningsadresser för historiktjänsten till Git-bridge. Vi behöver konfigurera dessa historikadresser så att de är åtkomliga från Git-bridge-containern.

Server Pro-containerkonfiguration:

* Ställ in `GIT_BRIDGE_ENABLED` till `'true'`
* Ställ in `GIT_BRIDGE_HOST` till `<git-bridge-container-namn>` t.ex. `git-bridge`
* Ställ in `GIT_BRIDGE_PORT` till `8000`
* Ställ in `V1_HISTORY_URL` till `http://<server-pro sibling container name>:3100/api`.

  Obs: Detta behövs endast på syskoncontainern för Git-bridge-containern. De andra instanserna kan använda en localhost-URL, vilket är standard.

Konfiguration för git-bridge-container:

* Ställ in `GIT_BRIDGE_API_BASE_URL` till `http://<server-pro sibling container name>/api/v0`, t.ex. `http://server-pro-ha-1/api/v0`
* Ställ in `GIT_BRIDGE_OAUTH2_SERVER` till `http://<server-pro sibling container name>`, t.ex. `http://server-pro-ha-1`
* Ställ in `GIT_BRIDGE_POSTBACK_BASE_URL` till `http://<git-bridge container name>:8000`, t.ex. `http://git-bridge:8000`
* Ställ in `GIT_BRIDGE_ROOT_DIR` till den monterade git-bridge-datadisken, t.ex. `/data/git-bridge`

<details>

<summary>Exempelkonfiguration för docker-compose.yml</summary>

Följande konfiguration visar en fristående uppsättning. För att demon ska fungera behöver du tillhandahålla en giltig SSL-nyckel/certifikat och justera `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` för versioner `4.x` och tidigare). För en faktisk installation måste du ersätta dummy-hemligheterna med riktiga hemligheter som anges i kommentarerna. För en faktisk installation behöver du flytta de enskilda containrarna till dedikerade noder och justera IP-adresserna till din lokala nätverkskonfiguration.

```yaml
version: '2.2'

# Faktisk installation med horisontell skalning: välj ditt eget nätverk och ersätt IP-adresserna i konfigurationen.
networks:
    default:
        ipam:
            config:
                # Detta subnät är en del av ett reserverat subnät som används för benchmarking
                # https://tools.ietf.org/html/rfc2544
                # Hela subnätet är 198.18.0.0/15
                # Använd 198.18.0.0/24 för lastbalanserare och databaser
                # Använd 198.18.1.0/24 för server-pro
                # Använd 198.18.0.128/25 för tillfällig container
                - gateway: 198.18.0.1
                  ip_range: 198.18.0.128/25
                  subnet: 198.18.0.0/23

services:
    # Faktisk installation med horisontell skalning: kör haproxy utanför docker på en separat värd.
    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
        # Alternativ till "ports": använd värdnätverk för att undvika overhead från docker-proxy
        network_mode: host

        # Alternativ till "network_mode: host": använd docker-proxy för nätverksisolering
        # ports:
        #     - "80:80"
        #     - "443:443"
        # networks:
        #     default:
        #         ipv4_address: 198.18.0.2

        # Faktisk horisontell skalning: ta bort dessa eftersom de körs på andra värdar.
        depends_on:
            server-pro-ha-1:
                condition: service_started
            server-pro-ha-2:
                condition: service_started
            server-pro-ha-3:
                condition: service_started

    # Faktisk horisontell skalning: kör denna container bredvid server-pro-ha-1.
    # För Server Pro 4.0 och senare.
    git-bridge:
        restart: always
        # Taggen bör matcha containertaggen `server-pro-ha-1`.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumes:
            # Faktisk horisontell skalning: peka /data/git-bridge på en dedikerad lokal 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"]

        # Faktisk horisontell skalning: kör på värd 198.18.0.6 och exponera port
        # ports:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Faktisk horisontell skalning: kör denna container på en separat värd.
    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:
            # Faktisk horisontell skalning: behåll denna post.
            git-bridge:
                condition: service_started

            # Faktisk horisontell skalning: ta bort de nedan eftersom de körs på andra värdar.
            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
            # Faktisk horisontell skalning: ange din egen domän/ditt eget appnamn.
            OVERLEAF_SITE_URL: 'https://overleaf.example.com'
            OVERLEAF_APP_NAME: Server Pro-demo för horisontell skalning

            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
            # Faktisk horisontell skalning: välj säkra autentiseringsuppgifter.
            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
            # Behövs bara på syskoninstansen av git-bridge
            V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
            # /git-bridge

            # Horisontell skalning
            # Faktisk horisontell skalning: välj säkra autentiseringsuppgifter.
            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'
            # Faktisk konfiguration för horisontell skalning: IP-adresser för lastbalanserare
            TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
            # /Horisontell skalning

        # Faktisk konfiguration för horisontell skalning: kör på värden 198.18.1.1 och exponera portar
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.1

    # Faktisk horisontell skalning: kör denna container på en separat värd.
    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"

        # Faktisk konfiguration för horisontell skalning: kör på värden 198.18.1.2 och exponera portar
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.2

    # Faktisk horisontell skalning: kör denna container på en separat värd.
    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"

        # Faktisk konfiguration för horisontell skalning: kör på värden 198.18.1.3 och exponera portar
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.3

    # Faktisk horisontell skalning: kör denna container på en separat värd.
    minio:
        image: minio/minio:RELEASE.2023-05-18T00-05-36Z
        container_name: minio
        command: server /data
        volumes:
            # Faktisk konfiguration för horisontell skalning: kör minio med flera diskar, se minios dokumentation.
            - ~/minio_data:/data
        environment:
            # Faktisk horisontell skalning: välj säkra autentiseringsuppgifter.
            MINIO_ROOT_USER: MINIO_ROOT_USER
            MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

        # Faktisk konfiguration för horisontell skalning: kör på värden 198.18.0.5 och exponera port
        # ports:
        #     - "9000:9000"
        networks:
            default:
                ipv4_address: 198.18.0.5

    # Faktisk konfiguration för horisontell skalning: kör den här konfigurationen en gång på en separat värd.
    minio_setup:
        depends_on:
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        kommandot:
            - '-c'
            # Faktisk horisontell skalning: välj säkra autentiseringsuppgifter.
            - |
                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

                # Lägg innehållet i policyn från föregående avsnitt i policy-filestore.json
                # Påminnelse: Byt ut bucket-namnen därefter.
                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

    # Faktisk horisontell skalning: kör denna container på en separat värd.
    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

        # Faktisk konfiguration för horisontell skalning: kör på värden 198.18.0.3 och exponera 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
        kommandot:
            - '-c'
            - |
                mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

    # Faktisk horisontell skalning: kör denna container på en separat värd.
    redis:
        restart: always
        image: redis:6.2
        container_name: redis
        expose:
            - 6379
        volumes:
            - ~/redis_data:/data

        # Faktisk konfiguration för horisontell skalning: kör på värden 198.18.0.4 och exponera port
        # ports:
        #     - "6379:6379"
        networks:
            default:
                ipv4_address: 198.18.0.4
```

</details>

#### Hårdvara

Vi rekommenderar att använda samma hårdvaruspecifikationer för alla Server Pro-instanser som deltar i horisontell skalning.

De allmänna rekommendationerna om [hårdvaruspecifikationer](/on-premises/sv/kom-igang/requirements/hardware-requirements.md) för Server Pro-instanser gäller.

#### Uppgradering av Server Pro

Som en del av uppgraderingsprocessen kör Server Pro automatiskt databasmigreringar. Dessa migreringar är **inte** utformade för att köras från flera instanser parallellt.

Migreringarna måste vara klara innan själva webbapplikationen startas. Du kan antingen kontrollera loggarna efter en post med `Migrations slutförda` eller vänta tills applikationen tar emot trafik.

Uppgraderingsproceduren ser ut så här:

1. Schemalägg ett underhållsfönster
2. Stoppa alla instanser av Server Pro
3. Ta en konsekvent säkerhetskopia enligt beskrivningen i [dokumentation](/on-premises/sv/underhall/data-and-backups.md#performing-a-consistent-backup)
4. Starta en enskild instans av Server Pro med den nya versionen
5. Verifiera att den nya instansen fungerar som förväntat
6. Starta de andra instanserna med den nya versionen


---

# 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/sv/underhall/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.