> ## 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.
# Горизонтальное масштабирование
Ayakaleaf Pro поддерживает горизонтальное масштабирование. Мы протестировали и проверили его корректную работу с несколькими репликами.
В этом документе перечислены технические требования и приведены рекомендации по запуску Ayakaleaf Pro более чем на одном узле.
Начиная с Server CE/Server Pro `5.0.3` переменные окружения были переименованы с `SHARELATEX_*` на `OVERLEAF_*`.
Если вы используете версию `4.x` (или более раннюю), убедитесь, что переменные имеют соответствующий префикс (например, `SHARELATEX_SITE_URL` вместо `OVERLEAF_SITE_URL`)
Настройка горизонтального масштабирования требует значительных усилий. Мы советуем рассматривать горизонтальное масштабирование **только** при достижении определённого масштаба. Например, установка Server Pro на 1 000 пользователей была успешно развёрнута на одном сервере с двумя 4-ядерными процессорами и 32 ГБ оперативной памяти. Рекомендации см. в документации по [требованиям к оборудованию](/ru/on-premises/getting-started/requirements/hardware-requirements).
Развёртывание Server Pro с горизонтальным масштабированием предполагает набор внешних компонентов, таких как балансировщик нагрузки и S3-совместимое хранилище.
Мы можем помочь в устранении ошибок в контейнерах Server Pro, которые могут быть вызваны неправильной настройкой, и дать общие рекомендации на основе этого документа. К сожалению, мы не можем оказывать помощь в настройке сторонних приложений/систем.
Решение технических проблем, связанных с вашим оборудованием/программным обеспечением, используемым для внешних компонентов, не входит в условия нашей поддержки.
### Требования
#### Внешнее централизованное хранилище данных
Хранилище данных в Server Pro можно разделить на четыре хранилища:
* **MongoDB**
* Большая часть данных сохраняется в MongoDB.
* Мы поддерживаем как локальный экземпляр, так и внешний, например [MongoDB](https://www.mongodb.com/atlas) Atlas (полностью управляемый сервис MongoDB, работающий в инфраструктуре AWS).
Примечание: к сожалению, в настоящее время нет официальной поддержки MongoDB-совместимых баз данных, таких как CosmoDB/DocumentDB, поскольку мы не тестировали с ними Server Pro. Хотя развёртывание Server Pro с совместимыми базами данных **может** быть возможным, официально мы поддерживаем только развёртывания с MongoDB.
* **Redis**
* Redis хранит временные данные, например ожидающие обновления документов до их сброса в MongoDB.
* Redis используется для передачи обновлений документов между различными сервисами и для уведомления редактора об изменениях состояния в конкретном проекте.
* Redis используется для хранения пользовательских сеансов.
* Мы поддерживаем как локальный экземпляр, так и внешний.
Примечание: к сожалению, в настоящее время нет официальной поддержки Redis-совместимых хранилищ ключ/значение, таких как KeyDB/Valkey, поскольку мы не тестировали с ними Server Pro. Хотя развёртывание Server Pro с совместимыми хранилищами **может** быть возможным, официально мы поддерживаем только развёртывания с Redis.
* **Файлы проектов и файлы истории**
* Нередактируемые файлы проектов хранятся вне MongoDB.
Новая система истории проектов (начиная с Server Pro 3.5) также хранит историю вне MongoDB.
* Для небольших одиночных экземпляров мы поддерживаем либо локальную файловую систему (которая может располагаться на локальном SSD, NFS или EBS), либо [S3-совместимую систему хранения данных](/ru/on-premises/configuration/overleaf-toolkit/s3).
* Для горизонтального масштабирования мы поддерживаем **только** S3-совместимые системы хранения данных.
Важно: NFS/Amazon EFS/Amazon EBS **не** поддерживаются для горизонтального масштабирования. Подробнее см. раздел требований к [хранилищу](/ru/on-premises/getting-started/requirements/hardware-requirements#storage), посвящённый масштабированию хранилища в Server Pro.
* **Временные файлы**
* Для оптимальной производительности компиляция LaTeX должна выполняться на быстрых локальных дисках. Результаты компиляции не нужно сохранять или резервировать.
* Буферизация загружаемых новых файлов и создание ZIP-архивов проектов также выигрывают от использования локального диска.
Мы настоятельно рекомендуем использовать локальный диск. Использование любого сетевого диска (например, NFS или EBS) может привести к неожиданным ошибкам компиляции и другим проблемам с производительностью.
#### **Git-bridge**
Git-bridge доступен в Server Pro начиная с версии 4.0.1.
Git-репозитории хранятся локально на диске. Возможности репликации отсутствуют. Git-bridge следует запускать в **единственном экземпляре**. Для оптимальной производительности мы рекомендуем использовать локальный диск для данных git-bridge. Диск с данными git-bridge следует регулярно резервировать.
Для хранения данных при горизонтальном масштабировании вам потребуются:
* центральный экземпляр MongoDB, доступный со всех экземпляров Server Pro
* центральный экземпляр Redis, доступный со всех экземпляров Server Pro
* центральное S3-совместимое хранилище для файлов проектов и истории
* локальный диск на каждом экземпляре для временных файлов
* локальный диск на экземпляре, где размещён контейнер git-bridge, для данных git-bridge
#### Требования к балансировщику нагрузки
* **Постоянная маршрутизация (sticky sessions)**, например с использованием cookie
Это требование обусловлено следующими компонентами:
* Функция редактирования в реальном времени в Server Pro использует WebSockets с резервным переходом на XHR polling. Каждый сеанс редактирования имеет локальное состояние на стороне сервера, и запросы конкретного сеанса редактирования всегда должны направляться на один и тот же экземпляр Server Pro. Функция совместной работы использует Redis [Pub/Sub](https://redis.io/docs/latest/develop/interact/pubsub/) для обмена обновлениями между несколькими экземплярами Server Pro.
* Компиляция LaTeX хранит результаты и кэш компиляции локально для повышения производительности. После отправки запроса на компиляцию одному экземпляру Server Pro последующие запросы на загрузку PDF/журнала должны направляться на тот же экземпляр Server Pro.
* **Длительные тайм-ауты запросов** для поддержки компиляции больших документов LaTeX
* **Поддержка WebSocket** для оптимальной производительности
* **Размер полезной нагрузки POST 50 МБ**
* **Тайм-аут keep-alive** должен быть меньше тайм-аута keep-alive в Server Pro
Тайм-аут keep-alive в Server Pro настраивается с помощью переменной окружения `NGINX_KEEPALIVE_TIMEOUT`. Значение по умолчанию — 65 с.
При значении по умолчанию подойдёт тайм-аут keep-alive 60 с в балансировщике нагрузки.
При `NGINX_KEEPALIVE_TIMEOUT=120` балансировщик нагрузки может использовать 115 с.
* **IP-адреса клиентов**
Задайте в заголовке запроса `X-Forwarded-For` IP-адрес клиента.
* При **терминировании SSL**
Балансировщик нагрузки должен добавлять заголовок запроса `X-Forwarded-Proto: https`.
```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
**Секреты**
Экземпляры Server Pro должны использовать общие секреты:
* `WEB_API_PASSWORD` (аутентификация web api)
* `STAGING_PASSWORD` и `V1_HISTORY_PASSWORD` с одинаковым значением (аутентификация истории)
* `CRYPTO_RANDOM` (для cookie сеанса)
* `OT_JWT_AUTH_KEY` (аутентификация истории)
Каждому из этих секретов нужно задать собственное уникальное значение и использовать его совместно на всех экземплярах.
Если они не настроены и запросы пользователей направляются на разные экземпляры Server Pro, запросы не пройдут проверку аутентификации, и пользователи либо будут часто перенаправляться на страницу входа, либо их действия в интерфейсе будут неожиданно завершаться ошибкой.
Если секреты не настроены, Server Pro использует для каждого из них новое случайное значение на основе 32 случайных байт из `/dev/urandom` (256 случайных бит).
```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**
Укажите в `OVERLEAF_MONGO_URL` (`SHARELATEX_MONGO_URL` для версий `4.x` и более ранних) центральный экземпляр MongoDB.
**Redis**
Укажите в `OVERLEAF_REDIS_HOST` (`SHARELATEX_REDIS_HOST` для версий `4.x` и более ранних) и `REDIS_HOST` центральный экземпляр Redis.
**S3-совместимое хранилище для файлов проектов и истории**
Подробнее см. документацию по [S3-совместимому хранилищу](/ru/on-premises/configuration/overleaf-toolkit/s3).
**Временные файлы**
Достаточно стандартного bind-монтирования локального SSD в `/var/lib/overleaf` (`/var/lib/sharelatex` для версий `4.x` и более ранних). Обязательно укажите в `SANDBOXED_COMPILES_HOST_DIR` точку монтирования на хосте.
Мы настоятельно рекомендуем использовать локальный диск. Использование любого сетевого диска (например, NFS или EBS) может привести к неожиданным ошибкам компиляции и другим проблемам с производительностью.
**Настройка прокси**
* Задайте `OVERLEAF_BEHIND_PROXY=true` (`SHARELATEX_BEHIND_PROXY` для версий `4.x` и более ранних), чтобы получать точные IP-адреса клиентов.
* Задайте в `TRUSTED_PROXY_IPS` IP-адрес балансировщика нагрузки (можно указать несколько CIDR через запятую).
**Интеграция с Git-bridge**
Git-bridge доступен в Server Pro начиная с версии 4.0.1.
Контейнеру git-bridge нужен соседний (sibling) контейнер Server Pro для обработки входящих git-запросов. Этот соседний контейнер может также обслуживать обычный пользовательский трафик. В примере конфигурации первый экземпляр выступает соседним контейнером для git-bridge, но на самом деле эту роль может выполнять любой экземпляр.
Зачем назначать один контейнер Server Pro соседним для git-bridge? Server Pro выдаёт git-bridge URL-адреса загрузки сервиса истории. Эти URL истории необходимо настроить так, чтобы они были доступны из контейнера git-bridge.
Настройка контейнера Server Pro:
* Задайте `GIT_BRIDGE_ENABLED` значение `'true'`
* Задайте `GIT_BRIDGE_HOST` значение ``, например `git-bridge`
* Задайте `GIT_BRIDGE_PORT` значение `8000`
* Задайте `V1_HISTORY_URL` значение `http://:3100/api`.
Примечание: это необходимо только на соседнем контейнере для контейнера git-bridge. Остальные экземпляры могут использовать URL localhost, который задан по умолчанию.
Настройка контейнера git-bridge:
* Задайте `GIT_BRIDGE_API_BASE_URL` значение `http:///api/v0`, например `http://server-pro-ha-1/api/v0`
* Задайте `GIT_BRIDGE_OAUTH2_SERVER` значение `http://`, например `http://server-pro-ha-1`
* Задайте `GIT_BRIDGE_POSTBACK_BASE_URL` значение `http://:8000`, например `http://git-bridge:8000`
* Задайте в `GIT_BRIDGE_ROOT_DIR` смонтированный (bind-mount) диск с данными git-bridge, например `/data/git-bridge`
Следующая конфигурация демонстрирует самодостаточную установку. Чтобы демонстрация заработала, необходимо предоставить действительный SSL-ключ/сертификат и изменить `OVERLEAF_SITE_URL` (`SHARELATEX_SITE_URL` для версий `4.x` и более ранних). Для реальной установки необходимо заменить фиктивные секреты настоящими, как указано в комментариях. Для реальной установки также нужно перенести отдельные контейнеры на выделенные узлы и скорректировать IP-адреса в соответствии с конфигурацией вашей локальной сети.
```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
```
#### Оборудование
Мы рекомендуем использовать одинаковые аппаратные характеристики для всех экземпляров Server Pro, участвующих в горизонтальном масштабировании.
Для экземпляров Server Pro действуют общие рекомендации по [аппаратным характеристикам](/ru/on-premises/getting-started/requirements/hardware-requirements).
#### Обновление Server Pro
В процессе обновления Server Pro автоматически выполняет миграции базы данных. Эти миграции **не** рассчитаны на параллельный запуск с нескольких экземпляров.
Миграции должны завершиться до запуска самого веб-приложения. Вы можете либо проверить журналы на наличие записи `Finished migrations`, либо дождаться, пока приложение начнёт принимать трафик.
Процедура обновления выглядит так:
1. Запланируйте окно обслуживания
2. Остановите все экземпляры Server Pro
3. Создайте согласованную резервную копию, как описано в [документации](/ru/on-premises/maintenance/data-and-backups#performing-a-consistent-backup)
4. Запустите один экземпляр Server Pro с новой версией
5. Убедитесь, что новый экземпляр работает как ожидается
6. Запустите остальные экземпляры с новой версией
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.