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

# Horisontal skalering

<Check>
  Ayakaleaf Pro understøtter horisontal skalering. Vi har testet og bekræftet, at det kører korrekt med flere replikaer.
</Check>

Dette dokument beskriver de tekniske krav og giver retningslinjer for at køre Ayakaleaf Pro på mere end én node.

<Danger>
  Fra og med Server CE/Server Pro `5.0.3` er miljøvariablerne blevet omdøbt fra `SHARELATEX_*` til `OVERLEAF_*`.

  Hvis du bruger en `4.x`-version (eller tidligere), skal du sørge for, at variablerne har det tilsvarende præfiks (f.eks. `SHARELATEX_SITE_URL` i stedet for `OVERLEAF_SITE_URL`)
</Danger>

Opsætning af horisontal skalering kræver en betydelig indsats. Vi råder til **kun** at overveje horisontal skalering, når man når en vis størrelse. For eksempel er en Server Pro-installation til i alt 1.000 brugere blevet sat op med succes på en enkelt server udstyret med to 4-kerne-processorer og 32 GB systemhukommelse. Se dokumentationen om [hardwarekrav](/da/on-premises/getting-started/requirements/hardware-requirements) for at få anbefalinger.

En installation af Server Pro med horisontal skalering omfatter en række eksterne komponenter, såsom en load balancer og et S3-kompatibelt lagringsbackend.

Vi kan hjælpe med fejlfinding af fejl i Server Pro-containerne, som kan skyldes forkert konfiguration, og give generelle råd baseret på dette dokument. Desværre kan vi ikke hjælpe med at konfigurere tredjepartsapplikationer/-systemer.

Løsning af tekniske problemer, der er specifikke for den hardware/software, du bruger til at levere de eksterne komponenter, er ikke dækket af vores supportvilkår.

### Krav

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

#### Eksternt, centralt datalager

Datalagringen i Server Pro kan opdeles i fire datalagre:

* **MongoDB**

  * Størstedelen af dataene gemmes i MongoDB.
  * Vi understøtter enten en lokal instans eller en ekstern instans, såsom [MongoDB](https://www.mongodb.com/atlas) Atlas (en fuldt administreret MongoDB-tjeneste, der kører i AWS-infrastrukturen).<br />

  <strong>Bemærk:</strong> Desværre er der i øjeblikket ingen officiel understøttelse af MongoDB-kompatible databaser som CosmoDB/DocumentDB, da vi ikke har testet Server Pro med dem. Selvom det **måske** er muligt at installere Server Pro med kompatible databaser, understøtter vi officielt kun installationer, der bruger MongoDB.<br />
* **Redis**

  * Redis gemmer midlertidige data, såsom ventende dokumentopdateringer, før de skrives til MongoDB.
  * Redis bruges til at formidle dokumentopdateringer mellem forskellige tjenester og til at underrette editoren om tilstandsændringer i et givet projekt.
  * Redis bruges til at gemme brugersessioner.
  * Vi understøtter enten en lokal instans eller en ekstern instans.<br />

  <strong>Bemærk:</strong> Desværre er der i øjeblikket ingen officiel understøttelse af Redis-kompatible key/value-lagre som KeyDB/Valkey, da vi ikke har testet Server Pro med dem. Selvom det **måske** er muligt at installere Server Pro med kompatible lagre, understøtter vi officielt kun installationer, der bruger Redis.<br />
* **Projektfiler og historikfiler**

  * Ikke-redigerbare projektfiler gemmes uden for MongoDB.

    Det nye projekthistoriksystem (Server Pro 3.5 og nyere) gemmer også historikken uden for MongoDB.
  * Til små enkeltinstanser understøtter vi enten et lokalt filsystem (som kan være baseret på en lokal SSD, NFS eller EBS) eller et [S3-kompatibelt datalagringssystem](/da/on-premises/configuration/overleaf-toolkit/s3).
  * Til horisontal skalering understøtter vi **kun** S3-kompatible datalagringssystemer.<br />

  <strong>Vigtigt:</strong> NFS/Amazon EFS/Amazon EBS understøttes **ikke** til horisontal skalering. Se afsnittet om krav til [hardwarelager](/da/on-premises/getting-started/requirements/hardware-requirements#storage) om skalering af lager i Server Pro for at få flere detaljer.
* **Midlertidige filer**
  * LaTeX-kompileringer skal køre på hurtige, lokale diske for at opnå optimal ydeevne. Kompileringsoutputtet behøver ikke at blive gemt permanent eller sikkerhedskopieret.
  * Buffering af nye filuploads og oprettelse af zip-filer med projekter har også fordel af at bruge en lokal disk.

<Danger>
  Vi anbefaler kraftigt at bruge en lokal disk. Brug af enhver form for netværksdisk (såsom NFS eller EBS) kan resultere i uventede kompileringsfejl og andre ydeevneproblemer.
</Danger>

#### **Git-bridge**

<Info>
  Git-bridge er tilgængelig i Server Pro fra og med version 4.0.1.
</Info>

Git-repositorierne gemmes lokalt på disken. Der er ingen replikeringsmuligheder. Git-bridge skal køres som en **singleton**. For at opnå optimal ydeevne anbefaler vi at bruge en lokal disk til git-bridge-data. Git-bridge-datadisken bør sikkerhedskopieres regelmæssigt.

Til datalagringen ved horisontal skalering skal du bruge:

* en central MongoDB-instans, der er tilgængelig fra alle Server Pro-instanser
* en central Redis-instans, der er tilgængelig fra alle Server Pro-instanser
* et centralt S3-kompatibelt lagringsbackend til projekt- og historikfiler
* en lokal disk på hver instans til midlertidige filer
* en lokal disk på den instans, der hoster git-bridge-containeren, til git-bridge-data

#### Krav til load balanceren

* **Vedvarende routing**, f.eks. ved hjælp af en cookie

  Dette krav skyldes følgende komponenter:

  * Realtidsredigeringen i Server Pro bruger WebSockets med XHR-polling som fallback. Hver redigeringssession har lokal tilstand på serversiden, og anmodningerne i en given redigeringssession skal altid routes til den samme Server Pro-instans. Samarbejdsfunktionen bruger Redis [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) til at dele opdateringer mellem flere Server Pro-instanser.
  * LaTeX-kompileringen gemmer output og kompileringscache lokalt af hensyn til ydeevnen. Når der sendes en kompileringsanmodning til én Server Pro-instans, skal de efterfølgende anmodninger om download af PDF/log routes til den samme Server Pro-instans.
* **Lange timeouts for anmodninger** for at understøtte kompilering af store LaTeX-dokumenter
* **WebSocket-understøttelse** for optimal ydeevne
* **POST-payloadstørrelse på 50 MB**
* **Keep-alive-timeout** skal være lavere end keep-alive-timeouten i Server Pro

  Keep-alive-timeouten i Server Pro kan konfigureres med miljøvariablen `NGINX_KEEPALIVE_TIMEOUT`. Standardværdien er 65 s.

  Med standardværdien fungerer en keep-alive-timeout på 60 s i load balanceren.

  Med `NGINX_KEEPALIVE_TIMEOUT=120` kan load balanceren vælge 115 s.
* **Klient-IP'er**

  Sæt anmodningsheaderen `X-Forwarded-For` til klientens IP.
* Ved **SSL-terminering**

  Load balanceren skal tilføje anmodningsheaderen `X-Forwarded-Proto: https`.

<Accordion title="Eksempel på HAProxy-konfiguration">
  ```text theme={null}
  global
    group haproxy
    user haproxy

    # Verbose logging
    log stdout format raw local0 debug

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

    # Verbose logging
    log                     global
    option                  httplog

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

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

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

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

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

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

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

  listen server-pro-ha-http
    bind :80
    http-request redirect scheme https unless { ssl_fc }

  listen server-pro-ha-https
    bind :443 ssl crt /etc/ssl/certs/ssl-key-and-certificate-bundle.pem

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

    # Tell the application the actual client ip
    option forwardfor

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

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

    # Debugging
    http-response add-header X-Served-By %s
    stats enable
    stats uri /haproxy

    server server-pro-ha-1 198.18.1.1:80 cookie server-pro-ha-1
    server server-pro-ha-2 198.18.1.2:80 cookie server-pro-ha-2
    server server-pro-ha-3 198.18.1.3:80 cookie server-pro-ha-3
  ```
</Accordion>

#### Konfiguration af Server Pro

**Hemmeligheder**

Server Pro-instanserne skal være enige om fælles hemmeligheder:

* `WEB_API_PASSWORD` (godkendelse af web-API)
* `STAGING_PASSWORD` og `V1_HISTORY_PASSWORD` med samme værdi (godkendelse af historik)
* `CRYPTO_RANDOM` (til sessionscookie)
* `OT_JWT_AUTH_KEY` (godkendelse af historik)

Alle disse hemmeligheder skal konfigureres med hver sin unikke værdi og deles mellem instanserne.

Hvis de ikke er konfigureret, og brugeranmodninger routes til forskellige Server Pro-instanser, vil anmodningerne fejle i godkendelseskontrollerne, og brugerne vil enten ofte blive omdirigeret til login-siden, eller deres handlinger i brugergrænsefladen vil fejle på uventede måder.

Hvis de ikke er konfigureret, bruger Server Pro en ny tilfældig værdi for hver hemmelighed baseret på 32 tilfældige bytes fra `/dev/urandom` (256 tilfældige bits).

```bash wrap theme={null}
# https://github.com/overleaf/overleaf/blob/45ca0f796c679103efd305ddbef28073c4a5de32/server-ce/init_scripts/00_regen_sharelatex_secrets.sh#L14
dd if=/dev/urandom bs=1 count=32 2>/dev/null | base64 -w 0 | rev | cut -b 2- | rev | tr -d '\n+/'
```

**MongoDB**

Lad `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` for version `4.x` og tidligere) pege på den centrale MongoDB-instans.

**Redis**

Lad `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` for version `4.x` og tidligere) og `REDIS_HOST` pege på den centrale Redis-instans.

**S3-kompatibelt lager til projekt- og historikfiler**

Se dokumentationen om [S3-kompatibelt lager](/da/on-premises/configuration/overleaf-toolkit/s3) for at få flere detaljer.

**Midlertidige filer**

Standard-bind-mountet af en lokal SSD til `/var/lib/overleaf` (`/var/lib/sharelatex` for version `4.x` og tidligere) er tilstrækkeligt. Sørg for at lade `SANDBOXED_COMPILES_HOST_DIR` pege på mountpunktet på værten.

<Danger>
  Vi anbefaler kraftigt at bruge en lokal disk. Brug af enhver form for netværksdisk (såsom NFS eller EBS) kan resultere i uventede kompileringsfejl og andre ydeevneproblemer.
</Danger>

**Proxykonfiguration**

* Sæt `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` for version `4.x` og tidligere) for at få korrekte klient-IP'er.
* Sæt `TRUSTED_PROXY_IPS` til load balancerens IP (flere CIDR'er kan angives, adskilt af komma).

**Git-bridge-integration**

<Info>
  Git-bridge er tilgængelig i Server Pro fra og med version 4.0.1.
</Info>

Git-bridge-containeren har brug for en søskende-container med Server Pro til at håndtere indgående git-anmodninger. Denne søskende-container kan også betjene almindelig brugertrafik. I eksempelkonfigurationen fungerer den første instans som søskende-container for git-bridge, men i praksis kan enhver instans udfylde den rolle.

Hvorfor skal vi udpege én Server Pro-container som søskende for git-bridge? Server Pro udleverer download-URL'er til historiktjenesten til git-bridge. Vi skal konfigurere disse historik-URL'er, så de er tilgængelige fra git-bridge-containeren.

Konfiguration af Server Pro-containeren:

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

  Bemærk: Dette er kun nødvendigt på søskende-containeren til git-bridge-containeren. De øvrige instanser kan bruge en localhost-URL, som er standard.

Konfiguration af git-bridge-containeren:

* Sæt `GIT_BRIDGE_API_BASE_URL` til `http://<server-pro sibling container name>/api/v0`, f.eks. `http://server-pro-ha-1/api/v0`
* Sæt `GIT_BRIDGE_OAUTH2_SERVER` til `http://<server-pro sibling container name>`, f.eks. `http://server-pro-ha-1`
* Sæt `GIT_BRIDGE_POSTBACK_BASE_URL` til `http://<git-bridge container name>:8000`, f.eks. `http://git-bridge:8000`
* Sæt `GIT_BRIDGE_ROOT_DIR` til den bind-mountede git-bridge-datadisk, f.eks. `/data/git-bridge`

<Accordion title="Eksempel på docker-compose.yml-konfiguration">
  Følgende konfiguration viser en selvstændig opsætning. For at demoen kan fungere, skal du angive en gyldig SSL-nøgle/-certifikat og tilpasse `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` for version `4.x` og tidligere). I en rigtig opsætning skal du erstatte dummy-hemmelighederne med rigtige hemmeligheder som angivet i kommentarerne. I en rigtig opsætning skal du flytte de enkelte containere over på dedikerede noder og tilpasse IP-adresserne til din lokale netværksopsætning.

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

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

  services:
      # Actual horizontal scaling setup: run haproxy outside docker on a separate host.
      lb:
          image: haproxy:2.6
          container_name: lb
          user: root
          logging:
              driver: local
              options:
                  max-size: 10g
                  max-file: '100'
          volumes:
              - ./haproxy.conf:/usr/local/etc/haproxy/haproxy.cfg
              # $ cat certificate.pem key.pem > ssl-key-and-certificate-bundle.pem
              - /path/to/ssl-key-and-certificate-bundle.pem:/etc/ssl/certs/ssl-key-and-certificate-bundle.pem
          # Alternative to "ports": use host network to avoid docker-proxy overhead
          network_mode: host

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

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

      # Actual horizontal scaling setup: run this container next to server-pro-ha-1.
      # For Server Pro 4.0 onwards.
      git-bridge:
          restart: always
          # The tag should match the `server-pro-ha-1` container tag.
          image: quay.io/sharelatex/git-bridge:4.0.1
          volumes:
              # Actual horizontal scaling setup: point /data/git-bridge at a dedicated local ssd.
              - ~/git_bridge_data:/data/git-bridge
          container_name: git-bridge
          environment:
              GIT_BRIDGE_API_BASE_URL: "http://server-pro-ha-1/api/v0"
              GIT_BRIDGE_OAUTH2_SERVER: "http://server-pro-ha-1"
              GIT_BRIDGE_POSTBACK_BASE_URL: "http://198.18.0.6:8000"
              GIT_BRIDGE_ROOT_DIR: "/data/git-bridge"
          user: root
          command: ["/server-pro-start.sh"]

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

      # Actual horizontal scaling setup: run this container on a separate host.
      server-pro-ha-1: &server-pro-ha-config
          restart: always
          image: quay.io/sharelatex/sharelatex-pro:4.0.1
          container_name: server-pro-ha-1
          hostname: server-pro-ha-1
          depends_on:
              # Actual horizontal scaling setup: keep this entry.
              git-bridge:
                  condition: service_started

              # Actual horizontal scaling setup: remove the ones below as they run on other hosts.
              mongo:
                  condition: service_healthy
              redis:
                  condition: service_started
              minio:
                  condition: service_started
              mongo_replica_set_setup:
                  condition: service_completed_successfully
              minio_setup:
                  condition: service_completed_successfully
          stop_grace_period: 60s
          volumes:
              - /tmp/scratch-disk1:/var/lib/sharelatex
              - /var/run/docker.sock:/var/run/docker.sock
          environment: &server-pro-ha-environment
              # Actual horizontal scaling setup: provide your own domain/app name.
              OVERLEAF_SITE_URL: 'https://overleaf.example.com'
              OVERLEAF_APP_NAME: Server Pro Horizontal Scaling Demo

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

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

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

              # S3
              # Actual horizontal scaling setup: pick secure credentials.
              OVERLEAF_FILESTORE_BACKEND: s3
              OVERLEAF_FILESTORE_USER_FILES_BUCKET_NAME: overleaf-user-files
              OVERLEAF_FILESTORE_TEMPLATE_FILES_BUCKET_NAME: overleaf-template-files
              OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID: OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID
              OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY: OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY
              OVERLEAF_FILESTORE_S3_ENDPOINT: http://198.18.0.5:9000
              OVERLEAF_FILESTORE_S3_PATH_STYLE: 'true'
              OVERLEAF_FILESTORE_S3_REGION: ''

              OVERLEAF_HISTORY_BACKEND: "s3"
              OVERLEAF_HISTORY_PROJECT_BLOBS_BUCKET: "overleaf-project-blobs"
              OVERLEAF_HISTORY_CHUNKS_BUCKET: "overleaf-chunks"
              OVERLEAF_HISTORY_S3_ACCESS_KEY_ID: "OVERLEAF_HISTORY_S3_ACCESS_KEY_ID"
              OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY: "OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY"
              OVERLEAF_HISTORY_S3_ENDPOINT: http://198.18.0.5:9000
              OVERLEAF_HISTORY_S3_PATH_STYLE: 'true'
              OVERLEAF_HISTORY_S3_REGION: ''
              # /S3

              # git-bridge
              GIT_BRIDGE_ENABLED: 'true'
              GIT_BRIDGE_HOST: 198.18.0.6
              GIT_BRIDGE_PORT: 8000
              # Only needed on the sibling instance of git-bridge
              V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
              # /git-bridge

              # Horizontal scaling
              # Actual horizontal scaling setup: pick secure credentials.
              WEB_API_PASSWORD: WEB_API_PASSWORD
              STAGING_PASSWORD: V1_HISTORY_PASSWORD
              V1_HISTORY_PASSWORD: V1_HISTORY_PASSWORD
              CRYPTO_RANDOM: CRYPTO_RANDOM
              OT_JWT_AUTH_KEY: OT_JWT_AUTH_KEY
              OVERLEAF_BEHIND_PROXY: 'true'
              # Actual horizontal scaling setup: IPs of load balancers
              TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
              # /Horizontal scaling

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

      # Actual horizontal scaling setup: run this container on a separate host.
      server-pro-ha-2:
          <<: *server-pro-ha-config
          hostname: server-pro-ha-2
          container_name: server-pro-ha-2
          volumes:
              - /tmp/scratch-disk2:/var/lib/sharelatex
              - /var/run/docker.sock:/var/run/docker.sock
          environment:
              <<: *server-pro-ha-environment
              SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk2/data/compiles'
              V1_HISTORY_URL: "http://localhost:3100/api"

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

      # Actual horizontal scaling setup: run this container on a separate host.
      server-pro-ha-3:
          <<: *server-pro-ha-config
          hostname: server-pro-ha-3
          container_name: server-pro-ha-3
          volumes:
              - /tmp/scratch-disk3:/var/lib/sharelatex
              - /var/run/docker.sock:/var/run/docker.sock
          environment:
              <<: *server-pro-ha-environment
              SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk3/data/compiles'
              V1_HISTORY_URL: "http://localhost:3100/api"

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

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

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

      # Actual horizontal scaling setup: run this setup once on a separate host.
      minio_setup:
          depends_on:
              - minio
          image: minio/mc:RELEASE.2023-05-18T16-59-00Z
          entrypoint: sh
          command:
              - '-c'
              # Actual horizontal scaling setup: pick secure credentials.
              - |
                  mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \
                  || sleep 10 && \
                  mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \
                  || sleep 10 && \
                  mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \
                  || sleep 10 && \
                  mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD

                  mc mb --ignore-existing s3/overleaf-user-files
                  mc mb --ignore-existing s3/overleaf-template-files
                  mc admin user add s3 \
                    OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID \
                    OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY

                  mc mb --ignore-existing s3/overleaf-project-blobs
                  mc mb --ignore-existing s3/overleaf-chunks
                  mc admin user add s3 \
                    OVERLEAF_HISTORY_S3_ACCESS_KEY_ID \
                    OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY

                  echo '
                    {
                      "Version": "2012-10-17",
                      "Statement": [
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:ListBucket"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-user-files"
                        },
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:PutObject",
                            "s3:GetObject",
                            "s3:DeleteObject"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-user-files/*"
                        },
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:ListBucket"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-template-files"
                        },
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:PutObject",
                            "s3:GetObject",
                            "s3:DeleteObject"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-template-files/*"
                        }
                      ]
                    }' > policy-filestore.json

                  echo '
                    {
                      "Version": "2012-10-17",
                      "Statement": [
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:ListBucket"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-project-blobs"
                        },
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:PutObject",
                            "s3:GetObject",
                            "s3:DeleteObject"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-project-blobs/*"
                        },
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:ListBucket"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-chunks"
                        },
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:PutObject",
                            "s3:GetObject",
                            "s3:DeleteObject"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-chunks/*"
                        }
                      ]
                    }' > policy-history.json

                  # Put the contents of the policy from the previous section in policy-filestore.json
                  # Reminder: Replace the bucket names accordingly.
                  mc admin policy create s3 overleaf-filestore policy-filestore.json
                  mc admin policy attach s3 overleaf-filestore \
                    --user=OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID || true

                  mc admin policy create s3 overleaf-history policy-history.json
                  mc admin policy attach s3 overleaf-history \
                    --user=OVERLEAF_HISTORY_S3_ACCESS_KEY_ID || true

      # Actual horizontal scaling setup: run this container on a separate host.
      mongo:
          restart: always
          image: mongo:4.4
          container_name: mongo
          command: "--replSet overleaf"
          expose:
              - 27017
          volumes:
              - ~/mongo_data:/data/db
          healthcheck:
              test: echo 'db.stats().ok' | mongo localhost:27017/test --quiet
              interval: 10s
              timeout: 10s
              retries: 5

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

      mongo_replica_set_setup:
          image: mongo:4.4
          entrypoint: sh
          depends_on:
              mongo:
                  condition: service_healthy
          command:
              - '-c'
              - |
                  mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

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

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

#### Hardware

Vi anbefaler at bruge de samme hardwarespecifikationer til alle de Server Pro-instanser, der indgår i den horisontale skalering.

De generelle anbefalinger om [hardwarespecifikationer](/da/on-premises/getting-started/requirements/hardware-requirements) for Server Pro-instanser gælder.

#### Opgradering af Server Pro

Som en del af opgraderingsprocessen kører Server Pro automatisk databasemigreringer. Disse migreringer er **ikke** designet til at blive kørt fra flere instanser parallelt.

Migreringerne skal være færdige, før selve webapplikationen startes. Du kan enten kontrollere loggene for en post med `Finished migrations` eller vente, til applikationen accepterer trafik.

Opgraderingsproceduren ser således ud:

1. Planlæg et vedligeholdelsesvindue
2. Stop alle instanser af Server Pro
3. Tag en konsistent sikkerhedskopi som beskrevet i [dokumentationen](/da/on-premises/maintenance/data-and-backups#performing-a-consistent-backup)
4. Start en enkelt instans af Server Pro med den nye version
5. Kontrollér, at den nye instans fungerer som forventet
6. Start de øvrige instanser med den nye version


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