> For the complete documentation index, see [llms.txt](https://ayakaleaf-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://ayakaleaf-pro.ayaka.space/on-premises/pl/konserwacja/horizontal-scaling.md).

# Skalowanie poziome

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

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` zmienne środowiskowe zostały przemianowane z `SHARELATEX_*` do `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 %}

Konfiguracja skalowania poziomego wymaga znacznego wysiłku. Zalecamy rozważenie skalowania poziomego **tylko** gdy zostanie osiągnięta określona skala. Na przykład instalacja Server Pro dla łącznie 1000 użytkowników została pomyślnie uruchomiona na jednym serwerze wyposażonym w dwa 4-rdzeniowe procesory i 32 GB pamięci systemowej. Zobacz [wymagania sprzętowe](/on-premises/pl/pierwsze-kroki/requirements/hardware-requirements.md) dokumentacji, aby uzyskać zalecenia.

Wdrożenie Server Pro ze skalowaniem poziomym obejmuje zestaw zewnętrznych komponentów, takich jak load balancer i magazyn zgodny z S3.

Możemy pomóc w diagnozowaniu błędów w kontenerach Server Pro, które mogą być wynikiem nieprawidłowej konfiguracji, oraz udzielić ogólnych wskazówek na podstawie tego dokumentu. Niestety nie jesteśmy w stanie zapewnić pomocy przy konfiguracji aplikacji/systemów firm trzecich.

Rozwiązywanie problemów technicznych specyficznych dla Twojego sprzętu/oprogramowania, aby zapewnić działanie komponentów zewnętrznych, nie jest objęte warunkami naszego wsparcia.

### Wymagania

#### Zewnętrzne, centralne przechowywanie danych

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

* **MongoDB**

  * Większość danych jest utrwalana w MongoDB.
  * Obsługujemy zarówno instancję lokalną, jak i 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 wspieramy wyłącznie wdrożenia korzystające z MongoDB.<br>
* **Redis**

  * Redis przechowuje dane tymczasowe, takie jak oczekujące aktualizacje dokumentów przed ich zapisaniem do MongoDB.
  * Redis jest używany do komunikowania aktualizacji dokumentów między różnymi usługami i powiadamiania edytora o zmianach stanu w danym projekcie.
  * Redis jest używany do przechowywania sesji użytkowników.
  * Obsługujemy zarówno instancję lokalną, jak i 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 wspieramy wyłącznie wdrożenia korzystające z Redis.<br>
* **Pliki projektu i pliki historii**

  * Niemodyfikowalne pliki projektu są przechowywane poza MongoDB.

    Nowy system historii projektu (od Server Pro 3.5) również przechowuje historię poza MongoDB.
  * W przypadku 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 przechowywania danych zgodny z S3](/on-premises/pl/konfiguracja/overleaf-toolkit/s3.md).
  * W przypadku skalowania poziomego **tylko** obsługujemy systemy przechowywania danych zgodne z S3.<br>

  **Ważne:** NFS/Amazon EFS/Amazon EBS są **nie** obsługiwane przy skalowaniu poziomym. Więcej informacji znajdziesz w sekcji [przechowywania sprzętowego](/on-premises/pl/pierwsze-kroki/requirements/hardware-requirements.md#storage) wymagań dotyczących skalowania pamięci masowej w Server Pro.
* **Pliki efemeryczne**
  * Kompilacje LaTeX muszą działać na szybkich, lokalnych dyskach, aby zapewnić optymalną wydajność. Wynik kompilacji nie musi być utrwalany ani archiwizowany.
  * 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. Używanie jakiegokolwiek dysku sieciowego (takiego jak NFS lub EBS) może skutkować nieoczekiwanymi błędami kompilacji i innymi problemami z wydajnością.
{% endhint %}

#### **Git-bridge**

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

Repozytoria git są przechowywane lokalnie na dysku. Nie ma dostępnych opcji replikacji. Git-bridge powinien działać jako **singleton**. Aby uzyskać optymalną wydajność, zalecamy używanie lokalnego dysku do danych git-bridge. Dysk z danymi git-bridge powinien być regularnie kopiowany zapasowo.

W przypadku przechowywania danych przy skalowaniu poziomym potrzebujesz:

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

#### Wymagania dotyczące load balancera

* **Trwałe routowanie**, np. za pomocą pliku cookie

  To wymaganie wynika z tych komponentów:

  * Funkcja edycji w czasie rzeczywistym w Server Pro używa WebSocketów z fallbackiem do odpytywania XHR. Każda sesja edycji ma stan lokalny 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 dla optymalnej wydajności. Po wysłaniu żądania kompilacji do jednej instancji Server Pro, następujące żądania pobrania PDF/logu muszą zostać skierowane do tej samej instancji Server Pro.
* **Długie limity czasu żądań** aby obsłużyć kompilację dużych dokumentów LaTeX
* **Obsługa WebSocket** dla optymalnej wydajności
* **Rozmiar ładunku POST 50 MB**
* **Limit 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ść domyślna to 65 s.

  Przy wartości domyślnej limit keep-alive 60 s w load balancerze działa poprawnie.

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

  Ustaw nagłówek żądania `X-Forwarded-For` na adres IP klienta.
* Gdy **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 „lepkie” połączenie nie działa
  option                  redispatch 1
  # Te ponowne próby dotyczą błędów połączenia TCP, a nie odpowiedzi HTTP 500
  retries                 3

  # „Lepka” sesja 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

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

  # Zezwól na wolne kompilacje -- twardy limit w clsi to 10 min
  timeout server          10m

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

  # Uwaga: Zachowanie keepalive w haproxy działa świetnie z domyślną konfiguracją keepalive w Server Pro.
  # Haproxy porządkuje połączenia w tle i w razie potrzeby będzie ponownie kierować żą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 przez 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;"

  # Skieruj 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ą uzgadniać współdzielone sekrety:

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

Wszystkie te sekrety muszą być 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ą albo często przekierowywane na stronę logowania, albo ich działania w interfejsie będą kończyć się nieoczekiwanymi błędami.

Jeśli nie zostaną skonfigurowane, Server Pro używa 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**

Wskaż `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` dla wersji `4.x` i wcześniejszych) w centralnej instancji MongoDB.

**Redis**

Wskaż `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` dla wersji `4.x` i wcześniejszych) oraz `REDIS_HOST` w centralnej instancji Redis.

**Przechowywanie S3 zgodne dla plików projektu i historii**

Proszę zapoznać się z dokumentacją na temat [magazyn zgodny z S3](/on-premises/pl/konfiguracja/overleaf-toolkit/s3.md) aby uzyskać szczegóły.

**Pliki efemeryczne**

Domyślny montaż bind lokalnego SSD do `/var/lib/overleaf` (`/var/lib/sharelatex` dla wersji `4.x` i wcześniejszych) będzie wystarczający. Pamiętaj, aby wskazać `SANDBOXED_COMPILES_HOST_DIR` na punkt montowania na hoście.

{% hint style="danger" %}
Zdecydowanie zalecamy używanie lokalnego dysku. Używanie jakiegokolwiek dysku sieciowego (takiego jak NFS lub EBS) może skutkować nieoczekiwanymi błędami kompilacji i innymi problemami 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 począwszy 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 też obsługiwać zwykły ruch użytkowników. W przykładowej konfiguracji pierwsza instancja pełni rolę sąsiedniego kontenera dla git-bridge, ale tak naprawdę dowolna instancja może 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` do `'true'`
* Ustaw `GIT_BRIDGE_HOST` do `<nazwa kontenera git-bridge>` np. `git-bridge`
* Ustaw `GIT_BRIDGE_PORT` do `8000`
* Ustaw `V1_HISTORY_URL` do `http://<nazwa sąsiedniego kontenera server-pro>:3100/api`.

  Uwaga: Jest to konieczne tylko w przypadku sąsiedniego kontenera dla kontenera git-bridge. Pozostałe instancje mogą używać adresu URL localhost, co jest ustawieniem domyślnym.

Konfiguracja kontenera git-bridge:

* Ustaw `GIT_BRIDGE_API_BASE_URL` do `http://<nazwa sąsiedniego kontenera server-pro>/api/v0`, np. `http://server-pro-ha-1/api/v0`
* Ustaw `GIT_BRIDGE_OAUTH2_SERVER` do `http://<nazwa sąsiedniego kontenera server-pro>`, np. `http://server-pro-ha-1`
* Ustaw `GIT_BRIDGE_POSTBACK_BASE_URL` do `http://<nazwa kontenera git-bridge>:8000`, np. `http://git-bridge:8000`
* Ustaw `GIT_BRIDGE_ROOT_DIR` do zamontowanego w bindzie dysku z danymi git-bridge, np. `/data/git-bridge`

<details>

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

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

```yaml
version: '2.2'

# Rzeczywista konfiguracja skalowania poziomego: 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 testów porównawczych
                # 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 dbs
                # Użyj 198.18.1.0/24 dla server-pro
                # Użyj 198.18.0.128/25 dla kontenera efemerycznego
                - gateway: 198.18.0.1
                  ip_range: 198.18.0.128/25
                  subnet: 198.18.0.0/23

services:
    # Rzeczywista konfiguracja skalowania poziomego: 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 dla izolacji sieci
        # ports:
        #     - "80:80"
        #     - "443:443"
        # networks:
        #     default:
        #         ipv4_address: 198.18.0.2

        # Rzeczywista konfiguracja skalowania poziomego: usuń te elementy, 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 poziomego: uruchom ten kontener obok server-pro-ha-1.
    # Dla Server Pro 4.0 i nowszych.
    git-bridge:
        restart: always
        # Tag powinien odpowiadać tagowi kontenera `server-pro-ha-1`.
        image: quay.io/sharelatex/git-bridge:4.0.1
        volumes:
            # Rzeczywista konfiguracja skalowania poziomego: 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 poziomego: uruchom na hoście 198.18.0.6 i udostępnij port
        # ports:
        #     - "8000:8000"
        networks:
            default:
                ipv4_address: 198.18.0.6

    # Rzeczywista konfiguracja skalowania poziomego: 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 poziomego: zachowaj ten wpis.
            git-bridge:
                condition: service_started

            # Rzeczywista konfiguracja skalowania poziomego: 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 poziomego: podaj własną domenę/nazwę aplikacji.
            OVERLEAF_SITE_URL: 'https://overleaf.example.com'
            OVERLEAF_APP_NAME: Demo skalowania poziomego Server Pro

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

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

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

            # S3
            # Rzeczywista konfiguracja skalowania poziomego: 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 poziomego: 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 poziomego: 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 poziomego: 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 poziomego: 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 poziomego: 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ę raz na oddzielnym hoście.
    minio_setup:
        depends_on:
            - minio
        image: minio/mc:RELEASE.2023-05-18T16-59-00Z
        entrypoint: sh
        polecenia:
            - '-c'
            # Rzeczywista konfiguracja skalowania poziomego: 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 zastąp 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 poziomego: 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 poziomego: 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 tych 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) mają zastosowanie do instancji Server Pro.

#### Aktualizacja Server Pro

W ramach procesu aktualizacji Server Pro automatycznie uruchamia migracje bazy danych. Te migracje są **nie** zaprojektowane tak, aby mogły być uruchamiane równolegle z wielu instancji.

Migracje muszą się zakończyć, zanim zostanie uruchomiona właściwa aplikacja webowa. Możesz albo sprawdzić w logach wpis `Zakończono migracje` albo 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ójny backup zgodnie z opisem w [dokumentacji](/on-premises/pl/konserwacja/data-and-backups.md#performing-a-consistent-backup)
4. Uruchom pojedynczą instancję Server Pro z nową wersją
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://ayakaleaf-pro.ayaka.space/on-premises/pl/konserwacja/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.