> 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/pl/utrzymanie/horizontal-scaling.md).

# Skalowanie poziome

Począwszy od wersji 3.5.6 Server Pro obsługuje skalowanie horyzontalne.

Ten dokument zawiera wymagania techniczne i wytyczne dotyczące uruchamiania Server Pro na więcej niż jednym węźle.

{% hint style="danger" %}
Począwszy od Server CE/Server Pro `5.0.3` zmieniono oznaczenie zmiennych środowiskowych z `SHARELATEX_*` na `OVERLEAF_*`.

Jeśli używasz `4.x` wersji (lub wcześniejszej), upewnij się, że zmienne mają odpowiedni prefiks (np. `SHARELATEX_SITE_URL` zamiast `OVERLEAF_SITE_URL`)
{% endhint %}

Skonfigurowanie skalowania horyzontalnego wymaga znacznego wysiłku. Zalecamy rozważenie skalowania horyzontalnego **tylko** gdy osiągnie się pewną skalę. Dla przykładu, instalację Server Pro dla łącznie 1000 użytkowników udało się skonfigurować przy użyciu jednego serwera wyposażonego w dwa 4-rdzeniowe procesory i 32 GB pamięci systemowej. Zobacz [wymagania sprzętowe](/on-premises/pl/pierwsze-kroki/requirements/hardware-requirements.md) dokumentację, aby poznać zalecenia.

Wdrożenie Server Pro ze skalowaniem horyzontalnym obejmuje zestaw zewnętrznych komponentów, takich jak load balancer i zaplecze pamięci masowej zgodne z S3.

Możemy pomóc w diagnozowaniu błędów w kontenerach Server Pro, które mogą być skutkiem błędnej konfiguracji, oraz udzielić ogólnych porad na podstawie tego dokumentu. Niestety nie możemy pomóc w konfigurowaniu aplikacji/systemów firm trzecich.

Rozwiązywanie problemów technicznych specyficznych dla Twojego sprzętu/oprogramowania, które dotyczą zapewnienia komponentów zewnętrznych, nie jest objęte naszymi warunkami wsparcia.

### Wymagania

#### Zewnętrzna, centralna pamięć danych

Pamięć danych w Server Pro można podzielić na cztery magazyny danych:

* **MongoDB**

  * Większość danych jest zapisywana w MongoDB.
  * Obsługujemy zarówno lokalną instancję, jak i instancję zewnętrzną, taką jak [MongoDB](https://www.mongodb.com/atlas) Atlas (w pełni zarządzana usługa MongoDB działająca w infrastrukturze AWS).<br>

  **Uwaga:** Niestety obecnie nie ma oficjalnego wsparcia dla baz danych zgodnych z MongoDB, takich jak CosmoDB/DocumentDB, ponieważ nie testowaliśmy Server Pro z nimi. Chociaż wdrożenie Server Pro z kompatybilnymi bazami danych **może** być możliwe, oficjalnie obsługujemy wyłącznie wdrożenia wykorzystujące MongoDB.<br>
* **Redis**

  * Redis przechowuje dane tymczasowe, takie jak oczekujące aktualizacje dokumentów przed ich zapisaniem do MongoDB.
  * Redis służy do komunikowania aktualizacji dokumentów między różnymi usługami oraz powiadamiania edytora o zmianach stanu w danym projekcie.
  * Redis służy do przechowywania sesji użytkowników.
  * Obsługujemy zarówno lokalną instancję, jak i instancję zewnętrzną.<br>

  **Uwaga:** Niestety obecnie nie ma oficjalnego wsparcia dla magazynów klucz/wartość zgodnych z Redis, takich jak KeyDB/Valkey, ponieważ nie testowaliśmy Server Pro z nimi. Chociaż wdrożenie Server Pro z kompatybilnymi magazynami **może** może być możliwe, oficjalnie obsługujemy wyłącznie wdrożenia wykorzystujące Redis.<br>
* **Pliki projektu i pliki historii**

  * Niezedytowalne pliki projektu są przechowywane poza MongoDB.

    Nowy system historii projektu (od Server Pro 3.5 wzwyż) również przechowuje historię poza MongoDB.
  * Dla małych pojedynczych instancji obsługujemy zarówno lokalny system plików (który może być oparty na lokalnym SSD, NFS lub EBS), jak i [system pamięci danych zgodny z S3](/on-premises/pl/konfiguracja/overleaf-toolkit/s3.md).
  * W przypadku skalowania horyzontalnego **tylko** obsługujemy systemy pamięci danych zgodne z S3.<br>

  **Ważne:** NFS/Amazon EFS/Amazon EBS są **nie** obsługiwane w skalowaniu horyzontalnym. Zobacz [wymagania dotyczące pamięci masowej](/on-premises/pl/pierwsze-kroki/requirements/hardware-requirements.md#storage) sekcję wymagań dotyczącą skalowania pamięci masowej w Server Pro, aby uzyskać więcej szczegółów.
* **Pliki tymczasowe**
  * Kompilacje LaTeX muszą być uruchamiane na szybkich, lokalnych dyskach, aby zapewnić optymalną wydajność. Wyniku kompilacji nie trzeba utrwalać ani archiwizować.
  * Buforowanie nowych przesyłanych plików oraz tworzenie archiwów ZIP projektu również korzysta z używania lokalnego dysku.

{% hint style="danger" %}
Zdecydowanie zalecamy używanie lokalnego dysku. Korzystanie z jakiegokolwiek dysku sieciowego (takiego jak NFS lub EBS) może prowadzić do nieoczekiwanych błędów kompilacji i innych problemów z wydajnością.
{% endhint %}

#### **Git-bridge**

{% hint style="info" %}
Git-bridge jest dostępny w Server Pro od wersji 4.0.1.
{% endhint %}

Repozytoria git są przechowywane lokalnie na dysku. Nie są dostępne opcje replikacji. Git-bridge powinien być uruchamiany jako **singleton**. Aby uzyskać optymalną wydajność, zalecamy używanie lokalnego dysku dla danych git-bridge. Dysk z danymi git-bridge powinien być regularnie archiwizowany.

Do przechowywania danych przy skalowaniu horyzontalnym potrzebujesz:

* centralnej instancji MongoDB dostępnej ze wszystkich instancji Server Pro
* centralnej instancji Redis dostępnej ze wszystkich instancji Server Pro
* centralnego zaplecza pamięci masowej zgodnego z S3 dla plików projektu i historii
* lokalnego dysku na każdej instancji dla plików tymczasowych
* lokalnego dysku na instancji hostującej kontener git-bridge dla danych git-bridge

#### Wymagania dotyczące load balancera

* **Trwałe trasowanie**, np. przy użyciu pliku cookie

  To wymaganie wynika z następujących komponentów:

  * Funkcja edycji w czasie rzeczywistym w Server Pro używa WebSocketów z zapasowym mechanizmem XHR polling. Każda sesja edycji ma lokalny stan po stronie serwera, a żądania danej sesji edycji zawsze muszą być kierowane do tej samej instancji Server Pro. Funkcja współpracy używa Redis [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) do udostępniania aktualizacji między wieloma instancjami Server Pro.
  * Kompilacja LaTeX przechowuje wynik i pamięć podręczną kompilacji lokalnie, aby zapewnić opcjonalnie lepszą wydajność. Po wysłaniu żądania kompilacji do jednej instancji Server Pro kolejne żądania pobrania PDF/log muszą zostać skierowane do tej samej instancji Server Pro.
* **Długie limity czasu żądań** aby obsługiwać kompilację dużych dokumentów LaTeX
* **Obsługa WebSocket** dla optymalnej wydajności
* **Rozmiar ładunku POST 50 MB**
* **Limit czasu keep-alive** musi być niższy niż limit keep-alive Server Pro

  Limit keep-alive w Server Pro można skonfigurować za pomocą zmiennej środowiskowej `NGINX_KEEPALIVE_TIMEOUT`. Wartością domyślną jest 65 s.

  Przy ustawieniu domyślnym działa limit keep-alive 60 s w load balancerze.

  Przy `NGINX_KEEPALIVE_TIMEOUT=120`, load balancer może ustawić 115 s.
* **Adresy IP klientów**

  Ustaw nagłówek żądania `X-Forwarded-For` na adres IP klienta.
* Kiedy **kończący SSL**

  Load balancer musi dodać nagłówek żądania `X-Forwarded-Proto: https`.

<details>

<summary>Przykładowa konfiguracja HAProxy</summary>

```
global
  group haproxy
  user haproxy

  # Szczegółowe logowanie
  log stdout format raw local0 debug

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

  # Szczegółowe logowanie
  log                     global
  option                  httplog

  # Przekieruj do innego backendu, jeśli przypięty jest niedostępny
  option                  redispatch 1
  # Te ponowienia dotyczą błędów połączenia TCP, a nie odpowiedzi HTTP ze statusem 500
  retries                 3

  # Utrzymanie sesji przez 24 h bezczynności — wynik kompilacji jest usuwany po 24 h
  cookie                  server-pro-ha insert maxidle 24h

  # Spróbuj połączyć się z dowolnym backendem przez 1 min, a następnie zwróć 503
  timeout queue           1m
  # Daj instancjom Server Pro 15 s na uruchomienie
  timeout connect         15s

  # Przerwij żądania od bardzo wolnych klientów (pozwól na 1 min bezczynności podczas odczytu żądania)
  timeout client          1m

  # Zezwól na wolne kompilacje — sztywny limit w clsi wynosi 10 min
  timeout server          10m

  # Rozłącz edytor po 23 h — 1 h wcześniej niż ich ostatnie użycie wczoraj
  timeout tunnel          23h

  # Uwaga: Zachowanie keepalive w haproxy działa świetnie z domyślną konfiguracją keepalive w Server Pro.
  # Haproxy czyści połączenia w tle i w razie potrzeby ponownie rozdzieli żądania.

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

  # Poinformuj aplikację, że działamy za HTTPS
  http-request set-header X-Forwarded-Proto https

  # Poinformuj aplikację o rzeczywistym adresie IP klienta
  option forwardfor

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

  # Kieruj ruch git do sąsiedniego kontenera git-bridge
  use-server server-pro-ha-1 if { path_beg /git/ }

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

#### Konfiguracja Server Pro

**Sekrety**

Instancje Server Pro muszą uzgodnić współdzielone sekrety:

* `WEB_API_PASSWORD` (uwierzytelnianie API web)
* `STAGING_PASSWORD` i `V1_HISTORY_PASSWORD` ta sama wartość (uwierzytelnianie historii)
* `CRYPTO_RANDOM` (dla pliku cookie sesji)
* `OT_JWT_AUTH_KEY` (uwierzytelnianie historii)

Wszystkie te sekrety muszą zostać skonfigurowane z własną unikalną wartością i współdzielone między instancjami.

Jeśli nie zostaną skonfigurowane, a żądania użytkowników będą kierowane do różnych instancji Server Pro, ich żądania nie przejdą kontroli uwierzytelniania i będą oni często przekierowywani na stronę logowania albo ich działania w interfejsie użytkownika będą kończyć się w nieoczekiwany sposób.

Jeśli nie zostaną skonfigurowane, Server Pro użyje nowej losowej wartości dla każdego sekretu, opartej na 32 losowych bajtach z `/dev/urandom` (256 losowych bitów).

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

Skieruj `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` dla wersji `4.x` i wcześniejszych) na centralną instancję MongoDB.

**Redis**

Skieruj `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` dla wersji `4.x` i wcześniejszych) oraz `REDIS_HOST` na centralnej instancji Redis.

**Pamięć masowa zgodna z S3 dla plików projektu i historii**

Zobacz dokumentację dotyczącą [magazyn zgodny z S3](/on-premises/pl/konfiguracja/overleaf-toolkit/s3.md) aby uzyskać szczegóły.

**Pliki tymczasowe**

Domyślne podmontowanie lokalnego SSD do `/var/lib/overleaf` (`/var/lib/sharelatex` dla wersji `4.x` i wcześniejszych) będzie wystarczające. Upewnij się, że wskażesz `SANDBOXED_COMPILES_HOST_DIR` punkt podmontowania na hoście.

{% hint style="danger" %}
Zdecydowanie zalecamy używanie lokalnego dysku. Korzystanie z jakiegokolwiek dysku sieciowego (takiego jak NFS lub EBS) może prowadzić do nieoczekiwanych błędów kompilacji i innych problemów z wydajnością.
{% endhint %}

**Konfiguracja proxy**

* Ustaw `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` dla wersji `4.x` i wcześniejszych) dla dokładnych adresów IP klientów.
* Ustaw `TRUSTED_PROXY_IPS` na adres IP load balancera (można podać wiele CIDR-ów, oddzielonych przecinkiem).

**Integracja Git-bridge**

{% hint style="info" %}
Git-bridge jest dostępny w Server Pro od wersji 4.0.1.
{% endhint %}

Kontener git-bridge potrzebuje sąsiedniego kontenera Server Pro do obsługi przychodzących żądań git. Ten sąsiedni kontener może również obsługiwać zwykły ruch użytkowników. W przykładowej konfiguracji pierwsza instancja pełni rolę kontenera sąsiedniego dla git-bridge, ale w rzeczywistości każda instancja mogłaby pełnić tę funkcję.

Dlaczego musimy wyznaczyć jeden kontener Server Pro jako sąsiedni dla git-bridge? Server Pro przekazuje git-bridge adresy URL pobierania dla usługi historii. Musimy skonfigurować te adresy URL historii tak, aby były dostępne z kontenera git-bridge.

Konfiguracja kontenera Server Pro:

* Ustaw `GIT_BRIDGE_ENABLED` na `'true'`
* Ustaw `GIT_BRIDGE_HOST` na `<git-bridge container name>` np. `git-bridge`
* Ustaw `GIT_BRIDGE_PORT` na `8000`
* Ustaw `V1_HISTORY_URL` na `http://<server-pro sibling container name>:3100/api`.

  Uwaga: Jest to konieczne tylko na sąsiednim kontenerze dla kontenera git-bridge. Pozostałe instancje mogą używać adresu URL localhost, który jest domyślny.

Konfiguracja kontenera git-bridge:

* Ustaw `GIT_BRIDGE_API_BASE_URL` na `http://<server-pro sibling container name>/api/v0`, np. `http://server-pro-ha-1/api/v0`
* Ustaw `GIT_BRIDGE_OAUTH2_SERVER` na `http://<server-pro sibling container name>`, np. `http://server-pro-ha-1`
* Ustaw `GIT_BRIDGE_POSTBACK_BASE_URL` na `http://<git-bridge container name>:8000`, np. `http://git-bridge:8000`
* Ustaw `GIT_BRIDGE_ROOT_DIR` do podmontowanego dysku danych git-bridge, np. `/data/git-bridge`

<details>

<summary>Przykładowa konfiguracja docker-compose.yml</summary>

Poniższa konfiguracja przedstawia samowystarczalny układ. Aby demo działało, musisz dostarczyć prawidłowy klucz/certyfikat SSL i dostosować `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` dla wersji `4.x` i wcześniejszych). W rzeczywistej konfiguracji musisz zastąpić przykładowe sekrety rzeczywistymi sekretami, zgodnie z komentarzami w tekście. W rzeczywistej konfiguracji musisz przenieść poszczególne kontenery na dedykowane węzły i dostosować adresy IP do swojej lokalnej konfiguracji sieci.

```yaml
version: '2.2'

# Rzeczywista konfiguracja skalowania horyzontalnego: wybierz własną sieć i zastąp adresy IP w konfiguracji.
networks:
    default:
        ipam:
            config:
                # Ta podsieć jest częścią zarezerwowanej podsieci używanej do benchmarków
                # https://tools.ietf.org/html/rfc2544
                # Cała podsieć to 198.18.0.0/15
                # Użyj 198.18.0.0/24 dla lb i baz danych
                # Użyj 198.18.1.0/24 dla server-pro
                # Użyj 198.18.0.128/25 dla kontenera tymczasowego
                - gateway: 198.18.0.1
                  ip_range: 198.18.0.128/25
                  subnet: 198.18.0.0/23

services:
    # Rzeczywista konfiguracja skalowania horyzontalnego: uruchom haproxy poza dockerem na osobnym hoście.
    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
        # Alternatywa dla "ports": użyj sieci hosta, aby uniknąć narzutu docker-proxy
        network_mode: host

        # Alternatywa dla "network_mode: host": użyj docker-proxy do izolacji sieci
        # ports:
        #     - "80:80"
        #     - "443:443"
        # networks:
        #     default:
        #         ipv4_address: 198.18.0.2

        # Rzeczywista konfiguracja skalowania horyzontalnego: usuń je, ponieważ działają na innych hostach.
        depends_on:
            server-pro-ha-1:
                condition: service_started
            server-pro-ha-2:
                condition: service_started
            server-pro-ha-3:
                condition: service_started

    # Rzeczywista konfiguracja skalowania horyzontalnego: uruchom ten kontener obok server-pro-ha-1.
    # Dla Server Pro 4.0 i nowszych.
    git-bridge:
        restart: always
        # Tagiem powinien być taki sam jak tag kontenera `server-pro-ha-1`.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumes:
            # Rzeczywista konfiguracja skalowania horyzontalnego: wskaż /data/git-bridge na dedykowany lokalny 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"]

        # Rzeczywista konfiguracja skalowania horyzontalnego: uruchom na hoście 198.18.0.6 i wystaw port
        # ports:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Rzeczywista konfiguracja skalowania horyzontalnego: uruchom ten kontener na osobnym hoście.
    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:
            # Rzeczywista konfiguracja skalowania horyzontalnego: zachowaj ten wpis.
            git-bridge:
                condition: service_started

            # Rzeczywista konfiguracja skalowania horyzontalnego: usuń poniższe, ponieważ działają na innych hostach.
            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
            # Rzeczywista konfiguracja skalowania horyzontalnego: podaj własną domenę/nazwę aplikacji.
            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
            # Rzeczywista konfiguracja skalowania horyzontalnego: wybierz bezpieczne dane uwierzytelniające.
            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
            # Potrzebne tylko na siostrzanej instancji git-bridge
            V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
            # /git-bridge

            # Skalowanie poziome
            # Rzeczywista konfiguracja skalowania horyzontalnego: wybierz bezpieczne dane uwierzytelniające.
            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'
            # Rzeczywista konfiguracja skalowania poziomego: adresy IP load balancerów
            TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
            # /Skalowanie poziome

        # Rzeczywista konfiguracja skalowania poziomego: uruchom na hoście 198.18.1.1 i wystaw porty
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.1

    # Rzeczywista konfiguracja skalowania horyzontalnego: uruchom ten kontener na osobnym hoście.
    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"

        # Rzeczywista konfiguracja skalowania poziomego: uruchom na hoście 198.18.1.2 i wystaw porty
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.2

    # Rzeczywista konfiguracja skalowania horyzontalnego: uruchom ten kontener na osobnym hoście.
    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"

        # Rzeczywista konfiguracja skalowania poziomego: uruchom na hoście 198.18.1.3 i wystaw porty
        # ports:
        #     - "80:80"
        networks:
            default:
                ipv4_address: 198.18.1.3

    # Rzeczywista konfiguracja skalowania horyzontalnego: uruchom ten kontener na osobnym hoście.
    minio:
        image: minio/minio:RELEASE.2023-05-18T00-05-36Z
        container_name: minio
        command: server /data
        volumes:
            # Rzeczywista konfiguracja skalowania poziomego: uruchom minio z wieloma dyskami, zobacz dokumentację minio.
            - ~/minio_data:/data
        environment:
            # Rzeczywista konfiguracja skalowania horyzontalnego: wybierz bezpieczne dane uwierzytelniające.
            MINIO_ROOT_USER: MINIO_ROOT_USER
            MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

        # Rzeczywista konfiguracja skalowania poziomego: uruchom na hoście 198.18.0.5 i wystaw port
        # ports:
        #     - "9000:9000"
        networks:
            default:
                ipv4_address: 198.18.0.5

    # Rzeczywista konfiguracja skalowania poziomego: uruchom tę konfigurację tylko raz na osobnym hoście.
    minio_setup:
        depends_on:
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        polecenia:
            - '-c'
            # Rzeczywista konfiguracja skalowania horyzontalnego: wybierz bezpieczne dane uwierzytelniające.
            - |
                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

                # Umieść zawartość polityki z poprzedniej sekcji w policy-filestore.json
                # Przypomnienie: odpowiednio zamień nazwy bucketów.
                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

    # Rzeczywista konfiguracja skalowania horyzontalnego: uruchom ten kontener na osobnym hoście.
    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

        # Rzeczywista konfiguracja skalowania poziomego: uruchom na hoście 198.18.0.3 i wystaw 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
        polecenia:
            - '-c'
            - |
                mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

    # Rzeczywista konfiguracja skalowania horyzontalnego: uruchom ten kontener na osobnym hoście.
    redis:
        restart: always
        image: redis:6.2
        container_name: redis
        expose:
            - 6379
        volumes:
            - ~/redis_data:/data

        # Rzeczywista konfiguracja skalowania poziomego: uruchom na hoście 198.18.0.4 i wystaw port
        # ports:
        #     - "6379:6379"
        networks:
            default:
                ipv4_address: 198.18.0.4
```

</details>

#### Sprzęt

Zalecamy używanie takich samych specyfikacji sprzętowych dla wszystkich instancji Server Pro biorących udział w skalowaniu poziomym.

Ogólne zalecenia dotyczące [specyfikacji sprzętowych](/on-premises/pl/pierwsze-kroki/requirements/hardware-requirements.md) dla instancji Server Pro mają zastosowanie.

#### Aktualizacja Server Pro

W ramach procesu aktualizacji Server Pro automatycznie uruchamia migracje bazy danych. Te migracje są **nie** zaprojektowane do uruchamiania równolegle z wielu instancji.

Migracje muszą zakończyć się przed uruchomieniem właściwej aplikacji internetowej. Możesz albo sprawdzić w logach wpis `Zakończono migracje` lub poczekać, aż aplikacja zacznie przyjmować ruch.

Procedura aktualizacji wygląda następująco:

1. Zaplanuj okno serwisowe
2. Zatrzymaj wszystkie instancje Server Pro
3. Wykonaj spójną kopię zapasową zgodnie z opisem w [dokumentację](/on-premises/pl/utrzymanie/data-and-backups.md#performing-a-consistent-backup)
4. Uruchom pojedynczą instancję Server Pro w nowej wersji
5. Sprawdź, czy nowa instancja działa zgodnie z oczekiwaniami
6. Uruchom pozostałe instancje z nową wersją


---

# 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/pl/utrzymanie/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.