Yatay ölçeklendirme

Ayakaleaf Pro yatay ölçeklendirmeyi destekler. Birden fazla replika ile doğru şekilde çalıştığını test ettik ve doğruladık.

Bu belge, Ayakaleaf Pro’yu birden fazla düğümde çalıştırmak için teknik gereksinimleri listeler ve yönergeler sunar.

Server CE/Server Pro 5.0.3 sürümünden itibaren ortam değişkenlerinin adı SHARELATEX_* yerine OVERLEAF_* olarak değiştirilmiştir.

4.x (veya daha eski) bir sürüm kullanıyorsanız, lütfen değişkenlerin buna uygun önekle yazıldığından emin olun (ör. OVERLEAF_SITE_URL yerine SHARELATEX_SITE_URL)

Yatay ölçeklendirmeyi kurmak önemli miktarda çaba gerektirir. Yatay ölçeklendirmeyi yalnızca belirli bir ölçeğe ulaşıldığında düşünmenizi öneririz. Örnek olarak, toplam 1.000 kullanıcılı bir Server Pro kurulumu, iki adet 4 çekirdekli işlemci ve 32GB sistem belleğiyle donatılmış tek bir sunucu kullanılarak başarıyla kurulmuştur. Öneriler için donanım gereksinimleri belgelerine bakın.

Yatay ölçeklendirmeli bir Server Pro kurulumu, Yük Dengeleyici ve S3 uyumlu depolama arka ucu gibi bir dizi harici bileşen içerir.

Server Pro konteynerlerinde yanlış yapılandırmadan kaynaklanabilecek hataların giderilmesine yardımcı olabilir ve bu belgeye dayanarak genel tavsiyeler sunabiliriz. Ne yazık ki üçüncü taraf uygulamaların/sistemlerin yapılandırılmasında yardım sağlayamıyoruz.

Harici bileşenleri sağlamak için kullandığınız donanıma/yazılıma özgü teknik sorunların çözümü destek koşullarımız kapsamında değildir.

​

Gereksinimler

​

Harici, merkezi veri depolama

Server Pro’daki veri depolama dört veri deposuna ayrılabilir:

• MongoDB

  • Verilerin çoğu MongoDB’de kalıcı olarak saklanır.
  • Yerel bir örneği veya MongoDB Atlas (AWS altyapısı içinde çalışan, tamamen yönetilen bir MongoDB hizmeti) gibi harici bir örneği destekliyoruz.
    

  Not: Ne yazık ki Server Pro’yu CosmoDB/DocumentDB gibi MongoDB uyumlu veritabanlarıyla test etmediğimiz için şu anda bunlara resmi destek bulunmamaktadır. Server Pro’yu uyumlu veritabanlarıyla dağıtmak mümkün olabilir, ancak resmi olarak yalnızca MongoDB kullanan kurulumları destekliyoruz.
  

• Redis

  • Redis, MongoDB’ye aktarılmadan önce bekleyen belge güncellemeleri gibi geçici verileri depolar.
  • Redis, farklı hizmetler arasında belge güncellemelerini iletmek ve belirli bir projedeki durum değişiklikleri hakkında düzenleyiciyi bilgilendirmek için kullanılır.
  • Redis, kullanıcı oturumlarını depolamak için kullanılır.
  • Yerel bir örneği veya harici bir örneği destekliyoruz.
    

  Not: Ne yazık ki Server Pro’yu KeyDB/Valkey gibi Redis uyumlu anahtar/değer depolarıyla test etmediğimiz için şu anda bunlara resmi destek bulunmamaktadır. Server Pro’yu uyumlu depolarla dağıtmak mümkün olabilir, ancak resmi olarak yalnızca Redis kullanan kurulumları destekliyoruz.
  

• Proje dosyaları ve Geçmiş dosyaları

  • Düzenlenemeyen proje dosyaları MongoDB dışında depolanır.

    Yeni proje geçmişi sistemi (Server Pro 3.5 ve sonrası) geçmişi de MongoDB dışında depolar.

  • Küçük tekil örnekler için yerel bir dosya sistemini (yerel bir SSD, NFS veya EBS ile desteklenebilir) ya da S3 uyumlu bir veri depolama sistemini destekliyoruz.

  • Yatay ölçeklendirme için yalnızca S3 uyumlu veri depolama sistemlerini destekliyoruz.
    

  Önemli: NFS/Amazon EFS/Amazon EBS yatay ölçeklendirme için desteklenmez. Daha fazla ayrıntı için lütfen Server Pro’da depolamanın ölçeklendirilmesine ilişkin donanım depolama gereksinimleri bölümüne bakın.

• Geçici dosyalar

  • LaTeX derlemelerinin en iyi performans için hızlı, yerel disklerde çalışması gerekir. Derleme çıktısının kalıcı olarak saklanmasına veya yedeklenmesine gerek yoktur.
  • Yeni dosya yüklemelerinin arabelleğe alınması ve proje zip dosyalarının oluşturulması da yerel disk kullanımından fayda sağlar.

Yerel disk kullanmanızı şiddetle öneririz. Herhangi bir ağ diski (NFS veya EBS gibi) kullanmak beklenmeyen derleme hatalarına ve diğer performans sorunlarına yol açabilir.

​

Git-bridge

Git-bridge, Server Pro’da 4.0.1 sürümünden itibaren kullanılabilir.

Git depoları yerel olarak diskte saklanır. Herhangi bir replikasyon seçeneği mevcut değildir. Git-bridge tekil (singleton) olarak çalıştırılmalıdır. En iyi performans için git-bridge verileri için yerel disk kullanmanızı öneririz. Git-bridge veri diski düzenli olarak yedeklenmelidir.

Yatay ölçeklendirmede veri depolama için şunlara ihtiyacınız vardır:

• tüm Server Pro örneklerinden erişilebilen merkezi bir MongoDB örneği
• tüm Server Pro örneklerinden erişilebilen merkezi bir Redis örneği
• proje ve geçmiş dosyaları için merkezi bir S3 uyumlu depolama arka ucu
• geçici dosyalar için her örnekte yerel bir disk
• git-bridge verileri için git-bridge konteynerini barındıran örnekte yerel bir disk

​

Yük dengeleyici gereksinimleri

• Kalıcı yönlendirme, ör. bir çerez kullanarak

  Bu gereksinim şu bileşenlerden kaynaklanır:

  • Server Pro’daki gerçek zamanlı düzenleme özelliği, XHR yoklamasına geri dönüş seçeneğiyle WebSocket’leri kullanır. Her düzenleme oturumunun sunucu tarafında yerel bir durumu vardır ve belirli bir düzenleme oturumunun istekleri her zaman aynı Server Pro örneğine yönlendirilmelidir. İşbirliği özelliği, güncellemeleri birden fazla Server Pro örneği arasında paylaşmak için Redis Pub/Sub kullanır.
  • LaTeX derlemesi, isteğe bağlı performans için çıktıyı ve derleme önbelleğini yerel olarak tutar. Bir Server Pro örneğine derleme isteği gönderildiğinde, ardından gelen PDF/günlük indirme isteklerinin de aynı Server Pro örneğine yönlendirilmesi gerekir.

• Büyük LaTeX belgelerinin derlenmesini desteklemek için uzun istek zaman aşımları

• En iyi performans için WebSocket desteği

• 50MB POST yük boyutu

• Keep-alive zaman aşımı, Server Pro keep-alive zaman aşımından düşük olmalıdır

  Server Pro’daki keep-alive zaman aşımı NGINX_KEEPALIVE_TIMEOUT ortam değişkeni kullanılarak yapılandırılabilir. Varsayılan değer 65 sn’dir.

  Varsayılan değerle, yük dengeleyicide 60 sn’lik bir keep-alive zaman aşımı çalışır.

  NGINX_KEEPALIVE_TIMEOUT=120 ile yük dengeleyici 115 sn seçebilir.

• İstemci IP’leri

  X-Forwarded-For istek başlığını istemci IP’sine ayarlayın.

• SSL sonlandırma yapılırken

  Yük dengeleyicinin X-Forwarded-Proto: https istek başlığını eklemesi gerekir.

Örnek HAProxy yapılandırması

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 yapılandırması

Gizli anahtarlar

Server Pro örneklerinin ortak gizli anahtarlar üzerinde uzlaşması gerekir:

• WEB_API_PASSWORD (web api kimlik doğrulaması)
• STAGING_PASSWORD ve V1_HISTORY_PASSWORD aynı değer (geçmiş kimlik doğrulaması)
• CRYPTO_RANDOM (oturum çerezi için)
• OT_JWT_AUTH_KEY (geçmiş kimlik doğrulaması)

Bu gizli anahtarların her biri kendine özgü benzersiz bir değerle yapılandırılmalı ve örnekler arasında paylaşılmalıdır.

Yapılandırılmadıklarında ve kullanıcı istekleri farklı Server Pro örneklerine yönlendirildiğinde, istekleri kimlik doğrulama kontrollerinde başarısız olur ve kullanıcılar ya sık sık giriş sayfasına yönlendirilir ya da arayüzdeki işlemleri beklenmedik şekillerde başarısız olur.

Yapılandırılmadığında Server Pro, her gizli anahtar için /dev/urandom’dan alınan 32 rastgele bayta (256 rastgele bit) dayanan yeni bir rastgele değer kullanır.

# 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 değişkenini (4.x ve önceki sürümler için SHARELATEX_MONGO_URL) merkezi MongoDB örneğine yönlendirin.

Redis

OVERLEAF_REDIS_HOST (4.x ve önceki sürümler için SHARELATEX_REDIS_HOST) ve REDIS_HOST değişkenlerini merkezi Redis örneğine yönlendirin.

Proje ve geçmiş dosyaları için S3 uyumlu depolama

Ayrıntılar için lütfen S3 uyumlu depolama belgelerine bakın.

Geçici dosyalar

Yerel bir SSD’nin /var/lib/overleaf (4.x ve önceki sürümler için /var/lib/sharelatex) konumuna varsayılan bind-mount’u yeterli olacaktır. SANDBOXED_COMPILES_HOST_DIR değişkenini ana makinedeki bağlama noktasına yönlendirdiğinizden emin olun.

Yerel disk kullanmanızı şiddetle öneririz. Herhangi bir ağ diski (NFS veya EBS gibi) kullanmak beklenmeyen derleme hatalarına ve diğer performans sorunlarına yol açabilir.

Proxy yapılandırması

• Doğru istemci IP’leri için OVERLEAF_BEHIND_PROXY=true (4.x ve önceki sürümler için SHARELATEX_BEHIND_PROXY) ayarlayın.
• TRUSTED_PROXY_IPS değişkenini yük dengeleyicinin IP’sine ayarlayın (virgülle ayrılmış birden fazla CIDR belirtilebilir).

Git-bridge entegrasyonu

Git-bridge, Server Pro’da 4.0.1 sürümünden itibaren kullanılabilir.

Git-bridge konteyneri, gelen git isteklerini işlemek için kardeş bir Server Pro konteynerine ihtiyaç duyar. Bu kardeş konteyner normal kullanıcı trafiğine de hizmet verebilir. Örnek yapılandırmada ilk örnek git-bridge için kardeş konteyner görevi görür, ancak aslında herhangi bir örnek bu işlevi üstlenebilir.

Neden bir Server Pro konteynerini git-bridge için kardeş olarak belirlememiz gerekiyor? Server Pro, geçmiş hizmeti için indirme URL’lerini git-bridge’e verir. Bu geçmiş URL’lerinin git-bridge konteynerinden erişilebilir olacak şekilde yapılandırılması gerekir.

Server Pro konteyner yapılandırması:

• GIT_BRIDGE_ENABLED değerini 'true' olarak ayarlayın

• GIT_BRIDGE_HOST değerini <git-bridge container name> olarak ayarlayın, ör. git-bridge

• GIT_BRIDGE_PORT değerini 8000 olarak ayarlayın

• V1_HISTORY_URL değerini http://<server-pro sibling container name>:3100/api olarak ayarlayın.

  Not: Bu yalnızca git-bridge konteynerinin kardeş konteynerinde gereklidir. Diğer örnekler varsayılan olan localhost URL’sini kullanabilir.

git-bridge konteyner yapılandırması:

• GIT_BRIDGE_API_BASE_URL değerini http://<server-pro sibling container name>/api/v0 olarak ayarlayın, ör. http://server-pro-ha-1/api/v0
• GIT_BRIDGE_OAUTH2_SERVER değerini http://<server-pro sibling container name> olarak ayarlayın, ör. http://server-pro-ha-1
• GIT_BRIDGE_POSTBACK_BASE_URL değerini http://<git-bridge container name>:8000 olarak ayarlayın, ör. http://git-bridge:8000
• GIT_BRIDGE_ROOT_DIR değerini bind-mount ile bağlanmış git-bridge veri diskine ayarlayın, ör. /data/git-bridge

Örnek docker-compose.yml yapılandırması

Aşağıdaki yapılandırma kendi kendine yeten bir kurulumu göstermektedir. Demonun çalışması için geçerli bir SSL anahtarı/sertifikası sağlamanız ve OVERLEAF_SITE_URL (4.x ve önceki sürümler için SHARELATEX_SITE_URL) değerini ayarlamanız gerekir. Gerçek bir kurulum için, satır içinde belirtildiği gibi sahte gizli anahtarları gerçek gizli anahtarlarla değiştirmeniz gerekir. Gerçek bir kurulum için ayrıca konteynerleri ayrı ayrı özel düğümlere taşımanız ve IP adreslerini yerel ağ kurulumunuza göre ayarlamanız gerekir.

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

​

Donanım

Yatay ölçeklendirmeye katılan tüm Server Pro örnekleri için aynı donanım özelliklerini kullanmanızı öneririz.

Server Pro örnekleri için genel donanım özellikleri önerileri geçerlidir.

​

Server Pro’yu yükseltme

Yükseltme sürecinin bir parçası olarak Server Pro, veritabanı geçişlerini otomatik olarak çalıştırır. Bu geçişler birden fazla örnekten paralel olarak çalıştırılmak üzere tasarlanmamıştır.

Geçişlerin, asıl web uygulaması başlatılmadan önce tamamlanması gerekir. Günlüklerde Finished migrations girdisini kontrol edebilir veya uygulama trafik kabul edene kadar bekleyebilirsiniz.

Yükseltme prosedürü şu şekildedir:

1. Bir bakım penceresi planlayın
2. Tüm Server Pro örneklerini durdurun
3. Belgelerde açıklandığı gibi tutarlı bir yedek alın
4. Yeni sürümle tek bir Server Pro örneği başlatın
5. Yeni örneğin beklendiği gibi çalıştığını doğrulayın
6. Diğer örnekleri yeni sürümle ayağa kaldırın