Горизонтальное масштабирование

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 ГБ оперативной памяти. Рекомендации см. в документации по требованиям к оборудованию.

Развёртывание Server Pro с горизонтальным масштабированием предполагает набор внешних компонентов, таких как балансировщик нагрузки и S3-совместимое хранилище.

Мы можем помочь в устранении ошибок в контейнерах Server Pro, которые могут быть вызваны неправильной настройкой, и дать общие рекомендации на основе этого документа. К сожалению, мы не можем оказывать помощь в настройке сторонних приложений/систем.

Решение технических проблем, связанных с вашим оборудованием/программным обеспечением, используемым для внешних компонентов, не входит в условия нашей поддержки.

​

Требования

​

Внешнее централизованное хранилище данных

Хранилище данных в Server Pro можно разделить на четыре хранилища:

• MongoDB

  • Большая часть данных сохраняется в MongoDB.
  • Мы поддерживаем как локальный экземпляр, так и внешний, например MongoDB 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-совместимую систему хранения данных.

  • Для горизонтального масштабирования мы поддерживаем только S3-совместимые системы хранения данных.
    

  Важно: NFS/Amazon EFS/Amazon EBS не поддерживаются для горизонтального масштабирования. Подробнее см. раздел требований к хранилищу, посвящённый масштабированию хранилища в 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 для обмена обновлениями между несколькими экземплярами 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.

Пример конфигурации HAProxy

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 случайных бит).

# 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-совместимому хранилищу.

Временные файлы

Достаточно стандартного 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 container name>, например git-bridge

• Задайте GIT_BRIDGE_PORT значение 8000

• Задайте V1_HISTORY_URL значение http://<server-pro sibling container name>:3100/api.

  Примечание: это необходимо только на соседнем контейнере для контейнера git-bridge. Остальные экземпляры могут использовать URL localhost, который задан по умолчанию.

Настройка контейнера git-bridge:

• Задайте GIT_BRIDGE_API_BASE_URL значение http://<server-pro sibling container name>/api/v0, например http://server-pro-ha-1/api/v0
• Задайте GIT_BRIDGE_OAUTH2_SERVER значение http://<server-pro sibling container name>, например http://server-pro-ha-1
• Задайте GIT_BRIDGE_POSTBACK_BASE_URL значение http://<git-bridge container name>:8000, например http://git-bridge:8000
• Задайте в GIT_BRIDGE_ROOT_DIR смонтированный (bind-mount) диск с данными git-bridge, например /data/git-bridge

Пример конфигурации docker-compose.yml

Следующая конфигурация демонстрирует самодостаточную установку. Чтобы демонстрация заработала, необходимо предоставить действительный SSL-ключ/сертификат и изменить OVERLEAF_SITE_URL (SHARELATEX_SITE_URL для версий 4.x и более ранних). Для реальной установки необходимо заменить фиктивные секреты настоящими, как указано в комментариях. Для реальной установки также нужно перенести отдельные контейнеры на выделенные узлы и скорректировать IP-адреса в соответствии с конфигурацией вашей локальной сети.

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 действуют общие рекомендации по аппаратным характеристикам.

​

Обновление Server Pro

В процессе обновления Server Pro автоматически выполняет миграции базы данных. Эти миграции не рассчитаны на параллельный запуск с нескольких экземпляров.

Миграции должны завершиться до запуска самого веб-приложения. Вы можете либо проверить журналы на наличие записи Finished migrations, либо дождаться, пока приложение начнёт принимать трафик.

Процедура обновления выглядит так:

1. Запланируйте окно обслуживания
2. Остановите все экземпляры Server Pro
3. Создайте согласованную резервную копию, как описано в документации
4. Запустите один экземпляр Server Pro с новой версией
5. Убедитесь, что новый экземпляр работает как ожидается
6. Запустите остальные экземпляры с новой версией