Escalabilidade horizontal

O Ayakaleaf Pro suporta escalabilidade horizontal. Testamos e verificamos que ele funciona corretamente com múltiplas réplicas.

Este documento lista os requisitos técnicos e fornece orientações para executar o Ayakaleaf Pro em mais de um nó.

A partir do Server CE/Server Pro 5.0.3, as variáveis de ambiente foram renomeadas de SHARELATEX_* para OVERLEAF_*.

Se estiver usando uma versão 4.x (ou anterior), certifique-se de que as variáveis tenham o prefixo correspondente (por exemplo, SHARELATEX_SITE_URL em vez de OVERLEAF_SITE_URL)

Configurar a escalabilidade horizontal exige um esforço considerável. Aconselhamos considerar a escalabilidade horizontal apenas ao atingir uma determinada escala. Como exemplo, uma instalação do Server Pro para 1.000 usuários no total foi configurada com sucesso num único servidor equipado com dois processadores de 4 núcleos e 32GB de memória. Consulte a documentação de requisitos de hardware para ver as recomendações.

Uma implantação do Server Pro com escalabilidade horizontal envolve um conjunto de componentes externos, como um balanceador de carga e um backend de armazenamento compatível com S3.

Podemos ajudar a diagnosticar erros nos contêineres do Server Pro que possam resultar de uma configuração incorreta e fornecer orientações gerais com base neste documento. Infelizmente, não podemos prestar assistência na configuração de aplicações/sistemas de terceiros.

A resolução de problemas técnicos específicos do seu hardware/software para fornecer os componentes externos não está coberta pelos nossos termos de suporte.

​

Requisitos

​

Armazenamento de dados externo e centralizado

O armazenamento de dados no Server Pro pode ser dividido em quatro repositórios de dados:

• MongoDB

  • A maior parte dos dados é persistida no MongoDB.
  • Suportamos uma instância local ou uma instância externa, como o MongoDB Atlas (um serviço MongoDB totalmente gerenciado que é executado na infraestrutura da AWS).
    

  Observação: infelizmente, não há suporte oficial para bancos de dados compatíveis com MongoDB, como CosmoDB/DocumentDB, no momento, pois não testamos o Server Pro com eles. Embora possa ser possível implantar o Server Pro com bancos de dados compatíveis, só oferecemos suporte oficial a implantações que usam o MongoDB.
  

• Redis

  • O Redis armazena dados temporários, como atualizações pendentes de documentos antes de serem gravadas no MongoDB.
  • O Redis é usado para comunicar atualizações de documentos entre diferentes serviços e notificar o editor sobre mudanças de estado num determinado projeto.
  • O Redis é usado para armazenar as sessões dos usuários.
  • Suportamos uma instância local ou uma instância externa.
    

  Observação: infelizmente, não há suporte oficial para armazenamentos de chave/valor compatíveis com Redis, como KeyDB/Valkey, no momento, pois não testamos o Server Pro com eles. Embora possa ser possível implantar o Server Pro com armazenamentos compatíveis, só oferecemos suporte oficial a implantações que usam o Redis.
  

• Arquivos de projeto e arquivos de histórico

  • Os arquivos de projeto não editáveis são armazenados fora do MongoDB.

    O novo sistema de histórico de projetos (Server Pro 3.5 em diante) também armazena o histórico fora do MongoDB.

  • Para instâncias únicas pequenas, suportamos um sistema de arquivos local (que pode ser baseado num SSD local, NFS ou EBS) ou um sistema de armazenamento de dados compatível com S3.

  • Para a escalabilidade horizontal, suportamos apenas sistemas de armazenamento de dados compatíveis com S3.
    

  Importante: NFS/Amazon EFS/Amazon EBS não são suportados para escalabilidade horizontal. Consulte a seção de requisitos de armazenamento de hardware sobre o dimensionamento do armazenamento no Server Pro para mais detalhes.

• Arquivos efêmeros

  • As compilações LaTeX precisam ser executadas em discos locais rápidos para um desempenho ideal. O resultado da compilação não precisa ser persistido nem copiado em backup.
  • O buffer de novos uploads de arquivos e a criação de arquivos zip de projetos também se beneficiam do uso de um disco local.

Recomendamos fortemente o uso de um disco local. Usar qualquer tipo de disco em rede (como NFS ou EBS) pode resultar em erros de compilação inesperados e outros problemas de desempenho.

​

Git-bridge

O Git-bridge está disponível no Server Pro a partir da versão 4.0.1.

Os repositórios git são armazenados localmente em disco. Não há opções de replicação disponíveis. O Git-bridge deve ser executado como singleton. Para um desempenho ideal, aconselhamos usar um disco local para os dados do git-bridge. O disco de dados do git-bridge deve ser copiado em backup regularmente.

Para o armazenamento de dados com escalabilidade horizontal, você precisa de:

• uma instância central do MongoDB acessível a partir de todas as instâncias do Server Pro
• uma instância central do Redis acessível a partir de todas as instâncias do Server Pro
• um backend de armazenamento central compatível com S3 para os arquivos de projeto e de histórico
• um disco local em cada instância para os arquivos efêmeros
• um disco local na instância que hospeda o contêiner do git-bridge para os dados do git-bridge

​

Requisitos do balanceador de carga

• Roteamento persistente, por exemplo usando um cookie

  Este requisito decorre destes componentes:

  • A capacidade de edição em tempo real do Server Pro usa WebSockets, com fallback para polling XHR. Cada sessão de edição tem estado local no lado do servidor, e as requisições de uma determinada sessão de edição precisam sempre ser roteadas para a mesma instância do Server Pro. O recurso de colaboração usa o Pub/Sub do Redis para partilhar atualizações entre várias instâncias do Server Pro.
  • A compilação LaTeX mantém o resultado e o cache de compilação localmente para melhor desempenho. Ao emitir uma requisição de compilação para uma instância do Server Pro, as requisições seguintes de download do PDF/log precisam ser roteadas para a mesma instância do Server Pro.

• Tempos limite de requisição longos para suportar a compilação de documentos LaTeX grandes

• Suporte a WebSocket para um desempenho ideal

• Tamanho de payload POST de 50MB

• O tempo limite de keep-alive deve ser inferior ao tempo limite de keep-alive do Server Pro

  O tempo limite de keep-alive no Server Pro pode ser configurado usando a variável de ambiente NGINX_KEEPALIVE_TIMEOUT. O valor padrão é 65s.

  Com o padrão, funciona um tempo limite de keep-alive de 60s no balanceador de carga.

  Com NGINX_KEEPALIVE_TIMEOUT=120, o balanceador de carga poderia usar 115s.

• IPs dos clientes

  Defina o cabeçalho de requisição X-Forwarded-For com o IP do cliente.

• Ao terminar o SSL

  O balanceador de carga precisa adicionar o cabeçalho de requisição X-Forwarded-Proto: https.

Exemplo de configuração do 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

​

Configuração do Server Pro

Segredos

As instâncias do Server Pro precisam compartilhar os mesmos segredos:

• WEB_API_PASSWORD (autenticação da web api)
• STAGING_PASSWORD e V1_HISTORY_PASSWORD com o mesmo valor (autenticação do histórico)
• CRYPTO_RANDOM (para o cookie de sessão)
• OT_JWT_AUTH_KEY (autenticação do histórico)

Todos estes segredos precisam ser configurados com o seu próprio valor único e compartilhados entre as instâncias.

Se não estiverem configurados e as requisições dos usuários forem roteadas para diferentes instâncias do Server Pro, as requisições falharão nas verificações de autenticação, e os usuários serão frequentemente redirecionados para a página de login ou as suas ações na interface falharão de formas inesperadas.

Quando não estão configurados, o Server Pro usa um novo valor aleatório para cada segredo, baseado em 32 bytes aleatórios de /dev/urandom (256 bits aleatórios).

# 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

Aponte OVERLEAF_MONGO_URL (SHARELATEX_MONGO_URL para as versões 4.x e anteriores) para a instância central do MongoDB.

Redis

Aponte OVERLEAF_REDIS_HOST (SHARELATEX_REDIS_HOST para as versões 4.x e anteriores) e REDIS_HOST para a instância central do Redis.

Armazenamento compatível com S3 para arquivos de projeto e de histórico

Consulte a documentação sobre armazenamento compatível com S3 para mais detalhes.

Arquivos efêmeros

O bind-mount padrão de um SSD local em /var/lib/overleaf (/var/lib/sharelatex para as versões 4.x e anteriores) será suficiente. Certifique-se de apontar SANDBOXED_COMPILES_HOST_DIR para o ponto de montagem no host.

Recomendamos fortemente o uso de um disco local. Usar qualquer tipo de disco em rede (como NFS ou EBS) pode resultar em erros de compilação inesperados e outros problemas de desempenho.

Configuração do proxy

• Defina OVERLEAF_BEHIND_PROXY=true (SHARELATEX_BEHIND_PROXY para as versões 4.x e anteriores) para obter IPs de cliente corretos.
• Defina TRUSTED_PROXY_IPS com o IP do balanceador de carga (é possível especificar vários CIDRs, separados por vírgula).

Integração com o Git-bridge

O Git-bridge está disponível no Server Pro a partir da versão 4.0.1.

O contêiner do git-bridge precisa de um contêiner irmão do Server Pro para processar as requisições git recebidas. Este contêiner irmão também pode atender ao tráfego normal dos usuários. Na configuração de exemplo, a primeira instância atua como contêiner irmão do git-bridge, mas na verdade qualquer instância poderia desempenhar esse papel.

Por que precisamos designar um contêiner do Server Pro como irmão do git-bridge? O Server Pro fornece ao git-bridge URLs de download do serviço de histórico. Precisamos configurar estas URLs de histórico para que sejam acessíveis a partir do contêiner do git-bridge.

Configuração do contêiner do Server Pro:

• Defina GIT_BRIDGE_ENABLED como 'true'

• Defina GIT_BRIDGE_HOST como <git-bridge container name>, por exemplo git-bridge

• Defina GIT_BRIDGE_PORT como 8000

• Defina V1_HISTORY_URL como http://<server-pro sibling container name>:3100/api.

  Observação: isto só é necessário no contêiner irmão do contêiner do git-bridge. As outras instâncias podem usar uma URL localhost, que é o padrão.

Configuração do contêiner do git-bridge:

• Defina GIT_BRIDGE_API_BASE_URL como http://<server-pro sibling container name>/api/v0, por exemplo http://server-pro-ha-1/api/v0
• Defina GIT_BRIDGE_OAUTH2_SERVER como http://<server-pro sibling container name>, por exemplo http://server-pro-ha-1
• Defina GIT_BRIDGE_POSTBACK_BASE_URL como http://<git-bridge container name>:8000, por exemplo http://git-bridge:8000
• Defina GIT_BRIDGE_ROOT_DIR como o disco de dados do git-bridge montado via bind-mount, por exemplo /data/git-bridge

Exemplo de configuração do docker-compose.yml

A configuração a seguir mostra uma instalação autônoma. Para que a demonstração funcione, é necessário fornecer uma chave/certificado SSL válido e ajustar o OVERLEAF_SITE_URL (SHARELATEX_SITE_URL para as versões 4.x e anteriores). Numa instalação real, você deve substituir os segredos fictícios por segredos reais, conforme indicado nos comentários. Numa instalação real, é necessário mover os contêineres individuais para nós dedicados e ajustar os endereços IP à configuração da sua rede local.

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

​

Hardware

Recomendamos usar as mesmas especificações de hardware para todas as instâncias do Server Pro que participam da escalabilidade horizontal.

Aplicam-se as recomendações gerais sobre as especificações de hardware das instâncias do Server Pro.

​

Atualizar o Server Pro

Como parte do processo de atualização, o Server Pro executa automaticamente migrações do banco de dados. Estas migrações não foram concebidas para serem executadas a partir de várias instâncias em paralelo.

As migrações precisam terminar antes de a aplicação web propriamente dita ser iniciada. Você pode verificar nos logs a entrada Finished migrations ou aguardar até que a aplicação aceite tráfego.

O procedimento de atualização é o seguinte:

1. Agende uma janela de manutenção
2. Pare todas as instâncias do Server Pro
3. Faça um backup consistente, conforme descrito na documentação
4. Inicie uma única instância do Server Pro com a nova versão
5. Verifique se a nova instância funciona como esperado
6. Inicie as outras instâncias com a nova versão