> ## 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 для 1000 користувачів загалом було успішно розгорнуто на одному сервері з двома 4-ядерними процесорами та 32 ГБ оперативної пам'яті. Рекомендації див. у документації щодо [апаратних вимог](/uk/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-сумісну систему зберігання даних](/uk/on-premises/configuration/overleaf-toolkit/s3).
* Для горизонтального масштабування ми підтримуємо **лише** S3-сумісні системи зберігання даних.
Важливо: NFS/Amazon EFS/Amazon EBS **не** підтримуються для горизонтального масштабування. Докладніше див. розділ вимог до [апаратного сховища](/uk/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 слід запускати як **singleton** (в одному екземплярі). Для оптимальної продуктивності радимо використовувати для даних git-bridge локальний диск. Диск із даними git-bridge слід регулярно резервувати.
Для зберігання даних із горизонтальним масштабуванням вам потрібні:
* центральний екземпляр MongoDB, доступний з усіх екземплярів Server Pro
* центральний екземпляр Redis, доступний з усіх екземплярів Server Pro
* центральне S3-сумісне сховище для файлів проєктів і історії
* локальний диск на кожному екземплярі для тимчасових файлів
* локальний диск на екземплярі, де розміщено контейнер git-bridge, для даних git-bridge
#### Вимоги до балансувальника навантаження
* **Постійна маршрутизація (sticky)**, наприклад за допомогою 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-запиту 50MB**
* **Тайм-аут keep-alive** має бути меншим за тайм-аут keep-alive у Server Pro
Тайм-аут keep-alive у Server Pro можна налаштувати за допомогою змінної середовища `NGINX_KEEPALIVE_TIMEOUT`. Значення за замовчуванням — 65s.
За типового значення працює тайм-аут keep-alive 60s у балансувальнику навантаження.
За `NGINX_KEEPALIVE_TIMEOUT=120` балансувальник навантаження може використовувати 115s.
* **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-сумісного сховища](/uk/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-змонтований диск даних 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, що беруть участь у горизонтальному масштабуванні.
Застосовуються загальні рекомендації щодо [апаратних характеристик](/uk/on-premises/getting-started/requirements/hardware-requirements) для екземплярів Server Pro.
#### Оновлення Server Pro
У межах процесу оновлення Server Pro автоматично виконує міграції бази даних. Ці міграції **не** розраховані на паралельний запуск із кількох екземплярів.
Міграції мають завершитися до запуску самого вебзастосунку. Можна або перевірити журнали на наявність запису `Finished migrations`, або дочекатися, доки застосунок почне приймати трафік.
Процедура оновлення виглядає так:
1. Заплануйте вікно технічного обслуговування
2. Зупиніть усі екземпляри Server Pro
3. Створіть узгоджену резервну копію, як описано в [документації](/uk/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.