> ## 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.
# Horizontale Skalierung
Ayakaleaf Pro unterstützt horizontale Skalierung. Wir haben getestet und bestätigt, dass es mit mehreren Replikaten korrekt läuft.
Dieses Dokument listet die technischen Anforderungen auf und bietet Richtlinien für den Betrieb von Ayakaleaf Pro auf mehr als einem Knoten.
Ab Server CE/Server Pro `5.0.3` wurden die Umgebungsvariablen von `SHARELATEX_*` in `OVERLEAF_*` umbenannt.
Wenn Sie eine `4.x`-Version (oder älter) verwenden, stellen Sie sicher, dass die Variablen das entsprechende Präfix tragen (z. B. `SHARELATEX_SITE_URL` statt `OVERLEAF_SITE_URL`)
Die Einrichtung einer horizontalen Skalierung erfordert erheblichen Aufwand. Wir empfehlen, horizontale Skalierung **nur** ab einer gewissen Größenordnung in Betracht zu ziehen. Beispielsweise wurde eine Server Pro-Installation für insgesamt 1.000 Benutzer erfolgreich auf einem einzigen Server mit zwei 4-Kern-Prozessoren und 32 GB Arbeitsspeicher eingerichtet. Empfehlungen finden Sie in der Dokumentation zu den [Hardwareanforderungen](/de/on-premises/getting-started/requirements/hardware-requirements).
Eine Bereitstellung von Server Pro mit horizontaler Skalierung umfasst eine Reihe externer Komponenten, etwa einen Load Balancer und ein S3-kompatibles Speicher-Backend.
Wir können bei der Fehlersuche in den Server Pro-Containern helfen, die auf eine Fehlkonfiguration zurückzuführen sein könnten, und auf Grundlage dieses Dokuments allgemeine Ratschläge geben. Leider können wir keine Unterstützung bei der Konfiguration von Drittanbieter-Anwendungen/-Systemen leisten.
Die Lösung technischer Probleme, die spezifisch für Ihre Hardware/Software zur Bereitstellung der externen Komponenten sind, ist nicht durch unsere Supportbedingungen abgedeckt.
### Anforderungen
#### Externer, zentraler Datenspeicher
Die Datenspeicherung in Server Pro lässt sich in vier Datenspeicher aufteilen:
* **MongoDB**
* Der Großteil der Daten wird in MongoDB gespeichert.
* Wir unterstützen entweder eine lokale oder eine externe Instanz, etwa [MongoDB](https://www.mongodb.com/atlas) Atlas (ein vollständig verwalteter MongoDB-Dienst, der innerhalb der AWS-Infrastruktur läuft).
Hinweis: Leider gibt es derzeit keine offizielle Unterstützung für MongoDB-kompatible Datenbanken wie CosmoDB/DocumentDB, da wir Server Pro nicht damit getestet haben. Auch wenn eine Bereitstellung von Server Pro mit kompatiblen Datenbanken **möglicherweise** funktioniert, unterstützen wir offiziell nur Bereitstellungen mit MongoDB.
* **Redis**
* Redis speichert temporäre Daten, etwa ausstehende Dokumentaktualisierungen, bevor sie in MongoDB geschrieben werden.
* Redis wird verwendet, um Dokumentaktualisierungen zwischen verschiedenen Diensten auszutauschen und den Editor über Zustandsänderungen in einem bestimmten Projekt zu benachrichtigen.
* Redis wird zum Speichern der Benutzersitzungen verwendet.
* Wir unterstützen entweder eine lokale oder eine externe Instanz.
Hinweis: Leider gibt es derzeit keine offizielle Unterstützung für Redis-kompatible Key/Value-Stores wie KeyDB/Valkey, da wir Server Pro nicht damit getestet haben. Auch wenn eine Bereitstellung von Server Pro mit kompatiblen Stores **möglicherweise** funktioniert, unterstützen wir offiziell nur Bereitstellungen mit Redis.
* **Projektdateien und Verlaufsdateien**
* Nicht bearbeitbare Projektdateien werden außerhalb von MongoDB gespeichert.
Das neue Projektverlaufssystem (ab Server Pro 3.5) speichert den Verlauf ebenfalls außerhalb von MongoDB.
* Für kleine Einzelinstanzen unterstützen wir entweder ein lokales Dateisystem (z. B. auf Basis einer lokalen SSD, NFS oder EBS) oder ein [S3-kompatibles Datenspeichersystem](/de/on-premises/configuration/overleaf-toolkit/s3).
* Für horizontale Skalierung unterstützen wir **ausschließlich** S3-kompatible Datenspeichersysteme.
Wichtig: NFS/Amazon EFS/Amazon EBS werden für horizontale Skalierung **nicht** unterstützt. Weitere Details zur Skalierung des Speichers in Server Pro finden Sie im Abschnitt zu den [Hardware-Speicheranforderungen](/de/on-premises/getting-started/requirements/hardware-requirements#storage).
* **Kurzlebige Dateien**
* LaTeX-Kompilierungen müssen für optimale Leistung auf schnellen, lokalen Datenträgern laufen. Die Ausgabe der Kompilierung muss nicht dauerhaft gespeichert oder gesichert werden.
* Auch das Puffern neuer Datei-Uploads und das Erstellen von Projekt-ZIP-Dateien profitieren von einem lokalen Datenträger.
Wir empfehlen dringend, einen lokalen Datenträger zu verwenden. Die Verwendung jeglicher Art von Netzwerkdatenträgern (wie NFS oder EBS) kann zu unerwarteten Kompilierungsfehlern und anderen Leistungsproblemen führen.
#### **Git-bridge**
Git-bridge ist in Server Pro ab Version 4.0.1 verfügbar.
Die Git-Repositorys werden lokal auf dem Datenträger gespeichert. Es stehen keine Replikationsoptionen zur Verfügung. Git-bridge sollte als **Singleton** betrieben werden. Für optimale Leistung empfehlen wir, für die Git-bridge-Daten einen lokalen Datenträger zu verwenden. Der Datenträger mit den Git-bridge-Daten sollte regelmäßig gesichert werden.
Für die Datenspeicherung bei horizontaler Skalierung benötigen Sie:
* eine zentrale MongoDB-Instanz, die von allen Server Pro-Instanzen aus erreichbar ist
* eine zentrale Redis-Instanz, die von allen Server Pro-Instanzen aus erreichbar ist
* ein zentrales S3-kompatibles Speicher-Backend für Projekt- und Verlaufsdateien
* einen lokalen Datenträger auf jeder Instanz für kurzlebige Dateien
* einen lokalen Datenträger auf der Instanz, die den Git-bridge-Container hostet, für die Git-bridge-Daten
#### Anforderungen an den Load Balancer
* **Persistentes Routing**, z. B. per Cookie
Diese Anforderung ergibt sich aus folgenden Komponenten:
* Die Echtzeit-Bearbeitung in Server Pro verwendet WebSockets mit einem Fallback auf XHR-Polling. Jede Bearbeitungssitzung hat einen lokalen Zustand auf der Serverseite, und die Anfragen einer bestimmten Bearbeitungssitzung müssen immer an dieselbe Server Pro-Instanz geleitet werden. Die Kollaborationsfunktion nutzt Redis [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/), um Aktualisierungen zwischen mehreren Server Pro-Instanzen auszutauschen.
* Die LaTeX-Kompilierung hält die Ausgabe und den Kompilierungs-Cache für optimale Leistung lokal vor. Nachdem eine Kompilierungsanfrage an eine Server Pro-Instanz gesendet wurde, müssen die nachfolgenden PDF-/Log-Download-Anfragen an dieselbe Server Pro-Instanz geleitet werden.
* **Lange Request-Timeouts** zur Unterstützung der Kompilierung großer LaTeX-Dokumente
* **WebSocket-Unterstützung** für optimale Leistung
* **POST-Payload-Größe von 50 MB**
* **Keep-alive-Timeout** muss niedriger sein als das Keep-alive-Timeout von Server Pro
Das Keep-alive-Timeout in Server Pro kann über die Umgebungsvariable `NGINX_KEEPALIVE_TIMEOUT` konfiguriert werden. Der Standardwert beträgt 65 s.
Mit dem Standardwert funktioniert ein Keep-alive-Timeout von 60 s im Load Balancer.
Mit `NGINX_KEEPALIVE_TIMEOUT=120` könnte der Load Balancer 115 s wählen.
* **Client-IPs**
Setzen Sie den Request-Header `X-Forwarded-For` auf die Client-IP.
* Beim **Terminieren von SSL**
Der Load Balancer muss den Request-Header `X-Forwarded-Proto: https` hinzufügen.
```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
```
#### Server Pro-Konfiguration
**Secrets**
Die Server Pro-Instanzen müssen gemeinsame Secrets verwenden:
* `WEB_API_PASSWORD` (Web-API-Authentifizierung)
* `STAGING_PASSWORD` und `V1_HISTORY_PASSWORD` mit demselben Wert (Verlaufs-Authentifizierung)
* `CRYPTO_RANDOM` (für das Sitzungscookie)
* `OT_JWT_AUTH_KEY` (Verlaufs-Authentifizierung)
Jedes dieser Secrets muss mit einem eigenen, eindeutigen Wert konfiguriert und zwischen den Instanzen geteilt werden.
Sind sie nicht konfiguriert und werden Benutzeranfragen an verschiedene Server Pro-Instanzen geleitet, schlagen die Authentifizierungsprüfungen fehl, und die Benutzer werden entweder häufig auf die Anmeldeseite umgeleitet oder ihre Aktionen in der Benutzeroberfläche schlagen auf unerwartete Weise fehl.
Sind sie nicht konfiguriert, verwendet Server Pro für jedes Secret einen neuen Zufallswert auf Basis von 32 zufälligen Bytes aus `/dev/urandom` (256 Zufallsbits).
```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**
Richten Sie `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` bei Versionen `4.x` und älter) auf die zentrale MongoDB-Instanz.
**Redis**
Richten Sie `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` bei Versionen `4.x` und älter) und `REDIS_HOST` auf die zentrale Redis-Instanz.
**S3-kompatibler Speicher für Projekt- und Verlaufsdateien**
Details finden Sie in der Dokumentation zu [S3-kompatiblem Speicher](/de/on-premises/configuration/overleaf-toolkit/s3).
**Kurzlebige Dateien**
Der standardmäßige Bind-Mount einer lokalen SSD nach `/var/lib/overleaf` (`/var/lib/sharelatex` bei Versionen `4.x` und älter) ist ausreichend. Achten Sie darauf, `SANDBOXED_COMPILES_HOST_DIR` auf den Mountpoint auf dem Host zu setzen.
Wir empfehlen dringend, einen lokalen Datenträger zu verwenden. Die Verwendung jeglicher Art von Netzwerkdatenträgern (wie NFS oder EBS) kann zu unerwarteten Kompilierungsfehlern und anderen Leistungsproblemen führen.
**Proxy-Konfiguration**
* Setzen Sie `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` bei Versionen `4.x` und älter), um korrekte Client-IPs zu erhalten.
* Setzen Sie `TRUSTED_PROXY_IPS` auf die IP des Load Balancers (mehrere CIDRs können durch Kommas getrennt angegeben werden).
**Git-bridge-Integration**
Git-bridge ist in Server Pro ab Version 4.0.1 verfügbar.
Der Git-bridge-Container benötigt einen Server Pro-Geschwistercontainer zur Verarbeitung eingehender Git-Anfragen. Dieser Geschwistercontainer kann auch regulären Benutzerverkehr bedienen. In der Beispielkonfiguration fungiert die erste Instanz als Geschwistercontainer für Git-bridge, grundsätzlich kann aber jede Instanz diese Rolle übernehmen.
Warum muss ein Server Pro-Container als Geschwister für Git-bridge festgelegt werden? Server Pro gibt Download-URLs für den Verlaufsdienst an Git-bridge aus. Diese Verlaufs-URLs müssen so konfiguriert werden, dass sie vom Git-bridge-Container aus erreichbar sind.
Konfiguration des Server Pro-Containers:
* Setzen Sie `GIT_BRIDGE_ENABLED` auf `'true'`
* Setzen Sie `GIT_BRIDGE_HOST` auf ``, z. B. `git-bridge`
* Setzen Sie `GIT_BRIDGE_PORT` auf `8000`
* Setzen Sie `V1_HISTORY_URL` auf `http://:3100/api`.
Hinweis: Dies ist nur auf dem Geschwistercontainer des Git-bridge-Containers erforderlich. Die anderen Instanzen können eine localhost-URL verwenden, was der Standard ist.
Konfiguration des Git-bridge-Containers:
* Setzen Sie `GIT_BRIDGE_API_BASE_URL` auf `http:///api/v0`, z. B. `http://server-pro-ha-1/api/v0`
* Setzen Sie `GIT_BRIDGE_OAUTH2_SERVER` auf `http://`, z. B. `http://server-pro-ha-1`
* Setzen Sie `GIT_BRIDGE_POSTBACK_BASE_URL` auf `http://:8000`, z. B. `http://git-bridge:8000`
* Setzen Sie `GIT_BRIDGE_ROOT_DIR` auf den per Bind-Mount eingebundenen Git-bridge-Datenträger, z. B. `/data/git-bridge`
Die folgende Konfiguration zeigt ein in sich geschlossenes Setup. Damit die Demo funktioniert, müssen Sie einen gültigen SSL-Schlüssel bzw. ein gültiges Zertifikat bereitstellen und `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` bei Versionen `4.x` und älter) anpassen. Für ein echtes Setup müssen Sie die Dummy-Secrets wie inline vermerkt durch echte Secrets ersetzen. Für ein echtes Setup müssen Sie außerdem die einzelnen Container auf dedizierte Knoten verschieben und die IP-Adressen an Ihr lokales Netzwerk anpassen.
```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
```
#### Hardware
Wir empfehlen, für alle an der horizontalen Skalierung beteiligten Server Pro-Instanzen dieselben Hardwarespezifikationen zu verwenden.
Es gelten die allgemeinen Empfehlungen zu den [Hardwarespezifikationen](/de/on-premises/getting-started/requirements/hardware-requirements) für Server Pro-Instanzen.
#### Server Pro aktualisieren
Im Rahmen des Upgrade-Prozesses führt Server Pro automatisch Datenbankmigrationen aus. Diese Migrationen sind **nicht** dafür ausgelegt, von mehreren Instanzen parallel ausgeführt zu werden.
Die Migrationen müssen abgeschlossen sein, bevor die eigentliche Webanwendung startet. Sie können entweder in den Logs nach dem Eintrag `Finished migrations` suchen oder warten, bis die Anwendung Datenverkehr annimmt.
Der Upgrade-Ablauf sieht wie folgt aus:
1. Planen Sie ein Wartungsfenster
2. Stoppen Sie alle Server Pro-Instanzen
3. Erstellen Sie ein konsistentes Backup wie in der [Dokumentation](/de/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) beschrieben
4. Starten Sie eine einzelne Server Pro-Instanz mit der neuen Version
5. Prüfen Sie, ob die neue Instanz wie erwartet funktioniert
6. Starten Sie die übrigen Instanzen mit der neuen Version
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.