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

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 ГБ оперативної пам’яті. Рекомендації див. у документації щодо апаратних вимог.

Розгортання 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 слід запускати як 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 для обміну оновленнями між кількома екземплярами 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.

Приклад конфігурації 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-змонтований диск даних 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. Запустіть інші екземпляри з новою версією