> 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/on-premises-no/vedlikehold/horizontal-scaling.md).

# Horisontal skalering

Fra og med versjon 3.5.6 støtter Server Pro horisontal skalering.

Dette dokumentet lister opp de tekniske kravene og gir retningslinjer for å kjøre Server Pro på mer enn én node.

{% hint style="danger" %}
Fra og med Server CE/Server Pro `5.0.3` miljøvariabler har blitt omdøpt fra `SHARELATEX_*` til `OVERLEAF_*`.

Hvis du bruker en `4.x` versjon (eller tidligere), må du sørge for at variablene har riktig prefiks (f.eks. `SHARELATEX_SITE_URL` i stedet for `OVERLEAF_SITE_URL`)
{% endhint %}

Å sette opp horisontal skalering krever en betydelig innsats. Vi anbefaler å vurdere horisontal skalering **bare** når man når en viss skala. Som et eksempel ble en Server Pro-installasjon for 1 000 totale brukere satt opp vellykket med en enkelt server utstyrt med to 4-kjerners prosessorer og 32 GB systemminne. Se [maskinvarekrav](/on-premises/on-premises-no/kom-i-gang/requirements/hardware-requirements.md) dokumentasjonen for anbefalinger.

En distribusjon av Server Pro med horisontal skalering innebærer et sett med eksterne komponenter, som en lastbalanserer og et S3-kompatibelt lagringsbackend.

Vi kan hjelpe med feilsøking av feil i Server Pro-containerne som kan skyldes feilkonfigurasjon, og gi generell veiledning basert på dette dokumentet. Dessverre kan vi ikke gi hjelp til konfigurasjon av tredjepartsapplikasjoner/-systemer.

Å løse tekniske problemer som er spesifikke for din maskinvare/programvare for å få de eksterne komponentene på plass, dekkes ikke av støttevilkårene våre.

### Krav

#### Ekstern, sentral datalagring

Datalagringen i Server Pro kan deles inn i fire datalagre:

* **MongoDB**

  * Det meste av dataene lagres i MongoDB.
  * Vi støtter enten en lokal instans eller en ekstern instans, som for eksempel [MongoDB](https://www.mongodb.com/atlas) Atlas (en fullstendig administrert MongoDB-tjeneste som kjører innenfor AWS-infrastrukturen).<br>

  **Merk:** Dessverre finnes det for øyeblikket ikke offisiell støtte for MongoDB-kompatible databaser som CosmoDB/DocumentDB, siden vi ikke har testet Server Pro med dem. Selv om det kan være mulig å distribuere Server Pro med kompatible databaser **kan** det, støtter vi bare distribusjoner som bruker MongoDB.<br>
* **Redis**

  * Redis lagrer midlertidige data, som ventende dokumentoppdateringer før de tømmes til MongoDB.
  * Redis brukes til å kommunisere dokumentoppdateringer mellom ulike tjenester og varsle editoren om statusendringer i et gitt prosjekt.
  * Redis brukes til å lagre brukersesjonene.
  * Vi støtter enten en lokal instans eller en ekstern instans.<br>

  **Merk:** Dessverre finnes det for øyeblikket ikke offisiell støtte for Redis-kompatible nøkkel-/verdi-databaser som KeyDB/Valkey, siden vi ikke har testet Server Pro med dem. Selv om det kan være mulig å distribuere Server Pro med kompatible lagre **kan** det, støtter vi bare distribusjoner som bruker Redis.<br>
* **Prosjektfiler og historikkfiler**

  * Prosjektfiler som ikke kan redigeres, lagres utenfor MongoDB.

    Det nye systemet for prosjekthistorikk (Server Pro 3.5 og nyere) lagrer også historikken utenfor MongoDB.
  * For små enkeltinstanser støtter vi enten et lokalt filsystem (som kan være støttet av en lokal SSD, NFS eller EBS) eller et [S3-kompatibelt datalagringssystem](/on-premises/on-premises-no/konfigurasjon/overleaf-toolkit/s3.md).
  * For horisontal skalering **bare** støtter vi S3-kompatible datalagringssystemer.<br>

  **Viktig:** NFS/Amazon EFS/Amazon EBS er **ikke** støttet for horisontal skalering. Se [maskinvarelagrings](/on-premises/on-premises-no/kom-i-gang/requirements/hardware-requirements.md#storage) kravdelen om skalering av lagring i Server Pro for mer informasjon.
* **Midlertidige filer**
  * LaTeX-kompileringer må kjøres på raske, lokale disker for optimal ytelse. Resultatet av kompileringen trenger ikke å persisteres eller sikkerhetskopieres.
  * Bufring av nye filopplastinger og opprettelse av prosjekt-zip-filer har også fordel av å bruke en lokal disk.

{% hint style="danger" %}
Vi anbefaler på det sterkeste å bruke en lokal disk. Bruk av enhver type nettverksdisk (som NFS eller EBS) kan føre til uventede kompileringfeil og andre ytelsesproblemer.
{% endhint %}

#### **Git-bridge**

{% hint style="info" %}
Git-bridge er tilgjengelig i Server Pro fra og med versjon 4.0.1.
{% endhint %}

Git-repositoriene lagres lokalt på disk. Det finnes ingen tilgjengelige replikeringsalternativer. Git-bridge bør kjøres som en **singleton**. For optimal ytelse anbefaler vi å bruke en lokal disk for git-bridge-data. Data-disken for git-bridge bør sikkerhetskopieres jevnlig.

For datalagringen med horisontal skalering trenger du:

* en sentral MongoDB-instans som er tilgjengelig fra alle Server Pro-instansene
* en sentral Redis-instans som er tilgjengelig fra alle Server Pro-instansene
* en sentral S3-kompatibel lagringsbackend for prosjekt- og historiefiler
* en lokal disk på hver instans for midlertidige filer
* en lokal disk på instansen som er vert for git-bridge-containeren for git-bridge-data

#### Krav til lastbalanserer

* **Vedvarende ruting**f.eks. ved å bruke en cookie

  Dette kravet skyldes disse komponentene:

  * Redigering i sanntid i Server Pro bruker WebSockets med fallback til XHR-polling. Hver redigeringsøkt har lokal tilstand på serversiden, og forespørslene fra en gitt redigeringsøkt må alltid rutes til den samme Server Pro-instansen. Samarbeidsfunksjonen bruker Redis [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) for å dele oppdateringer mellom flere Server Pro-instansene.
  * LaTeX-kompileringen holder utdataene og kompilasjonscachen lokalt for optimal ytelse. Når du sender en kompileringforespørsel til én Server Pro-instans, må de påfølgende forespørslene om nedlasting av PDF/logg rutes til den samme Server Pro-instansen.
* **Lange forespørselstimeouts** for å støtte kompilering av store LaTeX-dokumenter
* **WebSocket-støtte** for optimal ytelse
* **POST-payloadstørrelse på 50 MB**
* **Keep-alive-timeout** må være lavere enn keep-alive-timeouten i Server Pro

  Keep-alive-timeouten i Server Pro kan konfigureres ved hjelp av miljøvariabelen `NGINX_KEEPALIVE_TIMEOUT`. Standardverdien er 65 s.

  Med standardverdien fungerer en keep-alive-timeout på 60 s i lastbalansereren.

  Med `NGINX_KEEPALIVE_TIMEOUT=120`kan lastbalansereren bruke 115 s.
* **Klient-IP-er**

  Sett forespørselsheaderen `X-Forwarded-For` til klient-IP-en.
* Når **SSL-terminering**

  Lastbalansereren må legge til forespørselsheaderen `X-Forwarded-Proto: https`.

<details>

<summary>Eksempel på HAProxy-konfigurasjon</summary>

```
global
  group haproxy
  user haproxy

  # Utførlig logging
  log stdout format raw local0 debug

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

  # Utførlig logging
  log                     global
  option                  httplog

  # Ruter til en annen backend hvis den sticky-en er nede
  option                  redispatch 1
  # Disse forsøkene gjelder TCP-tilkoblingsfeil, ikke HTTP-status 500-svar
  retries                 3

  # Sticky-økt i 24 t uten aktivitet -- kompilasjonsutdata slettes etter 24 t
  cookie                  server-pro-ha insert maxidle 24h

  # Prøv å koble til hvilken som helst backend i 1 min, og returner deretter 503
  timeout queue           1m
  # Gi Server Pro-instansene 15 s til å starte opp
  timeout connect         15s

  # Avbryt forespørsler fra svært trege klienter (tillatt 1 min inaktivitet når en forespørsel leses)
  timeout client          1m

  # Tillat trege kompileringer -- hardkodet grense i clsi er 10 min
  timeout server          10m

  # Koble fra editoren etter 23 t -- 1 t før deres siste bruk i går
  timeout tunnel          23h

  # Merk: Keepalive-atferden i haproxy fungerer utmerket med standard keepalive-oppsettet i Server Pro.
  #       Haproxy rydder opp forbindelser i bakgrunnen, og den vil redispatche forespørsler når det trengs.

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

  # Si til applikasjonen at vi er bak https
  http-request set-header X-Forwarded-Proto https

  # Si til applikasjonen den faktiske klient-IP-en
  option forwardfor

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

  # Ruter git-trafikk til søskncontaineren til git-bridge
  use-server server-pro-ha-1 if { path_beg /git/ }

  # Feilsøking
  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-konfigurasjon

**Hemmeligheter**

Server Pro-instansene må være enige om delte hemmeligheter:

* `WEB_API_PASSWORD` (web-API-autentisering)
* `STAGING_PASSWORD` og `V1_HISTORY_PASSWORD` samme verdi (historieautentisering)
* `CRYPTO_RANDOM` (for sesjonscookie)
* `OT_JWT_AUTH_KEY` (historieautentisering)

Alle disse hemmelighetene må konfigureres med sin egen unike verdi og deles mellom instansene.

Når dette ikke er konfigurert, og brukerforespørsler sendes til ulike Server Pro-instansene, vil forespørslene deres feile autentiseringskontroller, og de blir enten ofte videresendt til innloggingssiden, eller handlingene deres i brukergrensesnittet vil feile på uventede måter.

Når dette ikke er konfigurert, bruker Server Pro en ny tilfeldig verdi for hver hemmelighet basert på 32 tilfeldige byte fra `/dev/urandom` (256 tilfeldige bit).

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

Pek `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` for versjoner `4.x` og tidligere) til den sentrale MongoDB-instansen.

**Redis**

Pek `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` for versjoner `4.x` og tidligere) og `REDIS_HOST` til den sentrale Redis-instansen.

**S3-kompatibel lagring for prosjekt- og historiefiler**

Se dokumentasjonen om [S3-kompatibel lagring](/on-premises/on-premises-no/konfigurasjon/overleaf-toolkit/s3.md) for detaljer.

**Midlertidige filer**

Standard bind-mount av en lokal SSD til `/var/lib/overleaf` (`/var/lib/sharelatex` for versjoner `4.x` og tidligere) vil være tilstrekkelig. Sørg for å peke `SANDBOXED_COMPILES_HOST_DIR` til monteringspunktet på verten.

{% hint style="danger" %}
Vi anbefaler på det sterkeste å bruke en lokal disk. Bruk av enhver type nettverksdisk (som NFS eller EBS) kan føre til uventede kompileringfeil og andre ytelsesproblemer.
{% endhint %}

**Proxykonfigurasjon**

* Sett `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` for versjoner `4.x` og tidligere) for korrekte klient-IP-er.
* Sett `TRUSTED_PROXY_IPS` til IP-en til lastbalansereren (flere CIDR-er kan spesifiseres, adskilt med komma).

**Integrasjon med git-bridge**

{% hint style="info" %}
Git-bridge er tilgjengelig i Server Pro fra og med versjon 4.0.1.
{% endhint %}

git-bridge-containeren trenger en søskncontainer med Server Pro for å håndtere innkommende git-forespørsler. Denne søskncontaineren kan også håndtere vanlig brukertrafikk. I eksempelkonfigurasjonen fungerer den første instansen som søskncontainer for git-bridge, men egentlig kunne hvilken som helst instans fungert som det.

Hvorfor trenger vi å utpeke én Server Pro-container som søskncontainer for git-bridge? Server Pro gir nedlastings-URL-er for historikktjenesten til git-bridge. Vi må konfigurere disse historie-URL-ene slik at de er tilgjengelige fra git-bridge-containeren.

Server Pro-containerkonfigurasjon:

* Sett `GIT_BRIDGE_ENABLED` til `'true'`
* Sett `GIT_BRIDGE_HOST` til `<git-bridge container name>` f.eks. `git-bridge`
* Sett `GIT_BRIDGE_PORT` til `8000`
* Sett `V1_HISTORY_URL` til `http://<server-pro sibling container name>:3100/api`.

  Merk: Dette er bare nødvendig på søskncontaineren for git-bridge-containeren. De andre instansene kan bruke en localhost-URL, som er standarden.

git-bridge-containerkonfigurasjon:

* Sett `GIT_BRIDGE_API_BASE_URL` til `http://<server-pro sibling container name>/api/v0`, f.eks. `http://server-pro-ha-1/api/v0`
* Sett `GIT_BRIDGE_OAUTH2_SERVER` til `http://<server-pro sibling container name>`, f.eks. `http://server-pro-ha-1`
* Sett `GIT_BRIDGE_POSTBACK_BASE_URL` til `http://<git-bridge container name>:8000`, f.eks. `http://git-bridge:8000`
* Sett `GIT_BRIDGE_ROOT_DIR` til den bind-monterte data-disken for git-bridge, f.eks. `/data/git-bridge`

<details>

<summary>Eksempel på docker-compose.yml-konfigurasjon</summary>

Den følgende konfigurasjonen viser et selvstendig oppsett. For at demoen skal fungere, må du oppgi en gyldig SSL-nøkkel/-sertifikat og justere `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` for versjoner `4.x` og tidligere). For et faktisk oppsett må du erstatte dummy-hemmelighetene med ekte hemmeligheter slik det er nevnt i linjene. For et faktisk oppsett må du flytte de enkelte containerne over på dedikerte noder og justere IP-adressene til nettverksoppsettet ditt.

```yaml
version: '2.2'

# Faktisk oppsett for horisontal skalering: velg ditt eget nettverk og erstatt IP-ene i konfigurasjonen.
networks:
    default:
        ipam:
            config:
                # Dette subnettet er en del av et reservert subnett som brukes til benchmarking
                # https://tools.ietf.org/html/rfc2544
                # Hele subnettet er 198.18.0.0/15
                # Bruk 198.18.0.0/24 for lb og dbs
                # Bruk 198.18.1.0/24 for server-pro
                # Bruk 198.18.0.128/25 for ephemeral container
                - gateway: 198.18.0.1
                  ip_range: 198.18.0.128/25
                  subnet: 198.18.0.0/23

tjenester:
    # Faktisk oppsett for horisontal skalering: kjør haproxy utenfor docker på en separat vert.
    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 til "ports": bruk host-nettverk for å unngå overhead fra docker-proxy
        network_mode: host

        # Alternativ til "network_mode: host": bruk docker-proxy for nettverksisolasjon
        # ports:
        #     - "80:80"
        #     - "443:443"
        # networks:
        #     default:
        #         ipv4_address: 198.18.0.2

        # Faktisk oppsett for horisontal skalering: fjern disse, siden de kjører på andre verter.
        depends_on:
            server-pro-ha-1:
                condition: service_started
            server-pro-ha-2:
                condition: service_started
            server-pro-ha-3:
                condition: service_started

    # Faktisk oppsett for horisontal skalering: kjør denne containeren ved siden av server-pro-ha-1.
    # For Server Pro 4.0 og nyere.
    git-bridge:
        restart: always
        # Taggen bør samsvare med container-taggen til `server-pro-ha-1`.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumes:
            # Faktisk oppsett for horisontal skalering: pek /data/git-bridge til en dedikert 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 oppsett for horisontal skalering: kjør på vert 198.18.0.6 og eksponer port
        # ports:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Faktisk oppsett for horisontal skalering: kjør denne containeren på en separat vert.
    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 oppsett for horisontal skalering: behold denne oppføringen.
            git-bridge:
                condition: service_started

            # Faktisk oppsett for horisontal skalering: fjern de nedenfor, siden de kjører på andre verter.
            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 oppsett for horisontal skalering: oppgi ditt eget domene/applikasjonsnavn.
            OVERLEAF_SITE_URL: 'https://overleaf.example.com'
            OVERLEAF_APP_NAME: Server Pro Horizontal Scaling Demo

            OVERLEAF_MONGO_URL: mongodb://198.18.0.3/sharelatex
            OVERLEAF_REDIS_HOST: 198.18.0.4
            REDIS_HOST: 198.18.0.4

            ENABLED_LINKED_FILE_TYPES: 'project_file,project_output_file'
            EMAIL_CONFIRMATION_DISABLED: 'true'

            SANDBOXED_COMPILES: 'true'
            SANDBOXED_COMPILES_SIBLING_CONTAINERS: 'true'
            SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk1/data/compiles'

            # S3
            # Faktisk oppsett for horisontal skalering: velg sikre legitimasjonsopplysninger.
            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
            # Bare nødvendig på søsterinstansen til git-bridge
            V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
            # /git-bridge

            # Horisontal skalering
            # Faktisk oppsett for horisontal skalering: velg sikre legitimasjonsopplysninger.
            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 oppsett for horisontal skalering: IP-adresser til lastbalanserne
            TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
            # /Horisontal skalering

        # Faktisk oppsett for horisontal skalering: kjør på vert 198.18.1.1 og eksponer porter
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.1

    # Faktisk oppsett for horisontal skalering: kjør denne containeren på en separat vert.
    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 oppsett for horisontal skalering: kjør på vert 198.18.1.2 og eksponer porter
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.2

    # Faktisk oppsett for horisontal skalering: kjør denne containeren på en separat vert.
    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 oppsett for horisontal skalering: kjør på vert 198.18.1.3 og eksponer porter
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.3

    # Faktisk oppsett for horisontal skalering: kjør denne containeren på en separat vert.
    minio:
        image: minio/minio:RELEASE.2023-05-18T00-05-36Z
        container_name: minio
        command: server /data
        volumes:
            # Faktisk oppsett for horisontal skalering: kjør minio med flere disker, se minio-dokumentasjonen.
            - ~/minio_data:/data
        environment:
            # Faktisk oppsett for horisontal skalering: velg sikre legitimasjonsopplysninger.
            MINIO_ROOT_USER: MINIO_ROOT_USER
            MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

        # Faktisk oppsett for horisontal skalering: kjør på vert 198.18.0.5 og eksponer port
        # ports:
        #     - "9000:9000"
        networks:
            default:
                ipv4_address: 198.18.0.5

    # Faktisk oppsett for horisontal skalering: kjør dette oppsettet én gang på en separat vert.
    minio_setup:
        depends_on:
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        kommandoen:
            - '-c'
            # Faktisk oppsett for horisontal skalering: velg sikre legitimasjonsopplysninger.
            - |
                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

                # Legg inn innholdet i policyen fra forrige seksjon i policy-filestore.json
                # Husk: Erstatt bøttenavnene tilsvarende.
                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 oppsett for horisontal skalering: kjør denne containeren på en separat vert.
    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 oppsett for horisontal skalering: kjør på vert 198.18.0.3 og eksponer 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
        kommandoen:
            - '-c'
            - |
                mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

    # Faktisk oppsett for horisontal skalering: kjør denne containeren på en separat vert.
    redis:
        restart: always
        image: redis:6.2
        container_name: redis
        expose:
            - 6379
        volumes:
            - ~/redis_data:/data

        # Faktisk oppsett for horisontal skalering: kjør på vert 198.18.0.4 og eksponer port
        # ports:
        #     - "6379:6379"
        networks:
            default:
                ipv4_address: 198.18.0.4
```

</details>

#### Maskinvare

Vi anbefaler å bruke de samme maskinvarespesifikasjonene for alle Server Pro-instansene som deltar i horisontal skalering.

De generelle anbefalingene om [maskinvarespesifikasjoner](/on-premises/on-premises-no/kom-i-gang/requirements/hardware-requirements.md) for Server Pro-instansene gjelder.

#### Oppgradering av Server Pro

Som en del av oppgraderingsprosessen kjører Server Pro automatisk database-migreringer. Disse migreringene er **ikke** utformet for å kjøres fra flere instanser parallelt.

Migreringene må fullføres før selve nettapplikasjonen startes. Du kan enten se i loggene etter en oppføring med `Migreringer fullført` eller vente til applikasjonen tar imot trafikk.

Oppgraderingsprosedyren ser slik ut:

1. Planlegg et vedlikeholdsvindu
2. Stopp alle instansene av Server Pro
3. Ta en konsistent sikkerhetskopi som beskrevet i [dokumentasjon](/on-premises/on-premises-no/vedlikehold/data-and-backups.md#performing-a-consistent-backup)
4. Start én instans av Server Pro med den nye versjonen
5. Kontroller at den nye instansen fungerer som forventet
6. Start de andre instansene med den nye versjonen


---

# 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/on-premises-no/vedlikehold/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.