> ## Documentation Index
> Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Escalabilidade horizontal

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

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

<Danger>
  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`)
</Danger>

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](/pt/on-premises/getting-started/requirements/hardware-requirements) 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

<Frame>
  <img src="https://mintcdn.com/ayakaleaf-pro/GmaXa-Cu4QQRFT4C/images/on-premises/img-f045c922.jpg?fit=max&auto=format&n=GmaXa-Cu4QQRFT4C&q=85&s=fc2eadc84a202a5ad07dd34ca6f903d4" alt="" width="2617" height="2319" data-path="images/on-premises/img-f045c922.jpg" />
</Frame>

#### 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](https://www.mongodb.com/atlas) Atlas (um serviço MongoDB totalmente gerenciado que é executado na infraestrutura da AWS).<br />

  <strong>Observação:</strong> 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.<br />
* **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.<br />

  <strong>Observação:</strong> 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.<br />
* **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](/pt/on-premises/configuration/overleaf-toolkit/s3).
  * Para a escalabilidade horizontal, suportamos **apenas** sistemas de armazenamento de dados compatíveis com S3.<br />

  <strong>Importante:</strong> NFS/Amazon EFS/Amazon EBS **não** são suportados para escalabilidade horizontal. Consulte a seção de requisitos de [armazenamento de hardware](/pt/on-premises/getting-started/requirements/hardware-requirements#storage) 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.

<Danger>
  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.
</Danger>

#### **Git-bridge**

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

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](https://redis.io/docs/latest/develop/interact/pubsub/) 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`.

<Accordion title="Exemplo de configuração do HAProxy">
  ```text theme={null}
  global
    group haproxy
    user haproxy

    # Verbose logging
    log stdout format raw local0 debug

  defaults
    mode                    http
    option                  httpchk HEAD /status
    http-check              expect status 200
    default-server          check

    # Verbose logging
    log                     global
    option                  httplog

    # Reroute to a different backend if the sticky one is down
    option                  redispatch 1
    # These retries are for TCP connect errors, not on HTTP status 500 responses
    retries                 3

    # Sticky session for 24h of inactivity -- compile output is deleted after 24h
    cookie                  server-pro-ha insert maxidle 24h

    # Try to connect to any backend for 1min, then return 503
    timeout queue           1m
    # Give Server Pro instances 15s to startup
    timeout connect         15s

    # Abort requests from very slow clients (allow 1min of inactivity when reading a request)
    timeout client          1m

    # Allow slow compiles -- hard-coded limit in clsi is 10min
    timeout server          10m

    # Disconnect the editor after 23h -- 1h ahead of their last use yesterday
    timeout tunnel          23h

    # Note: The keepalive behavior in haproxy works great with the default keepalive setup in Server Pro.
    #       Haproxy is cleaning up connections in the background and it will redispatch requests when needed.

  listen server-pro-ha-http
    bind :80
    http-request redirect scheme https unless { ssl_fc }

  listen server-pro-ha-https
    bind :443 ssl crt /etc/ssl/certs/ssl-key-and-certificate-bundle.pem

    # Tell the application that we are behind https
    http-request set-header X-Forwarded-Proto https

    # Tell the application the actual client ip
    option forwardfor

    # See https://hstspreload.org/#deployment-recommendations
    http-response set-header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload;"

    # Route git traffic to the sibling container of the git-bridge
    use-server server-pro-ha-1 if { path_beg /git/ }

    # Debugging
    http-response add-header X-Served-By %s
    stats enable
    stats uri /haproxy

    server server-pro-ha-1 198.18.1.1:80 cookie server-pro-ha-1
    server server-pro-ha-2 198.18.1.2:80 cookie server-pro-ha-2
    server server-pro-ha-3 198.18.1.3:80 cookie server-pro-ha-3
  ```
</Accordion>

#### 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).

```bash wrap theme={null}
# https://github.com/overleaf/overleaf/blob/45ca0f796c679103efd305ddbef28073c4a5de32/server-ce/init_scripts/00_regen_sharelatex_secrets.sh#L14
dd if=/dev/urandom bs=1 count=32 2>/dev/null | base64 -w 0 | rev | cut -b 2- | rev | tr -d '\n+/'
```

**MongoDB**

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](/pt/on-premises/configuration/overleaf-toolkit/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.

<Danger>
  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.
</Danger>

**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**

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

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`

<Accordion title="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.

  ```yaml theme={null}
  version: '2.2'

  # Actual horizontal scaling setup: pick your own network and replace IPs in config.
  networks:
      default:
          ipam:
              config:
                  # This subnet is part of a reserved subnet used for benchmarking
                  # https://tools.ietf.org/html/rfc2544
                  # The full subnet is 198.18.0.0/15
                  # Use 198.18.0.0/24 for lb and dbs
                  # Use 198.18.1.0/24 for server-pro
                  # Use 198.18.0.128/25 for ephemeral container
                  - gateway: 198.18.0.1
                    ip_range: 198.18.0.128/25
                    subnet: 198.18.0.0/23

  services:
      # Actual horizontal scaling setup: run haproxy outside docker on a separate host.
      lb:
          image: haproxy:2.6
          container_name: lb
          user: root
          logging:
              driver: local
              options:
                  max-size: 10g
                  max-file: '100'
          volumes:
              - ./haproxy.conf:/usr/local/etc/haproxy/haproxy.cfg
              # $ cat certificate.pem key.pem > ssl-key-and-certificate-bundle.pem
              - /path/to/ssl-key-and-certificate-bundle.pem:/etc/ssl/certs/ssl-key-and-certificate-bundle.pem
          # Alternative to "ports": use host network to avoid docker-proxy overhead
          network_mode: host

          # Alternative to "network_mode: host": use docker-proxy for network isolation
          # ports:
          #     - "80:80"
          #     - "443:443"
          # networks:
          #     default:
          #         ipv4_address: 198.18.0.2

          # Actual horizontal scaling setup: remove these as they run on other hosts.
          depends_on:
              server-pro-ha-1:
                  condition: service_started
              server-pro-ha-2:
                  condition: service_started
              server-pro-ha-3:
                  condition: service_started

      # Actual horizontal scaling setup: run this container next to server-pro-ha-1.
      # For Server Pro 4.0 onwards.
      git-bridge:
          restart: always
          # The tag should match the `server-pro-ha-1` container tag.
          image: quay.io/sharelatex/git-bridge:4.0.1
          volumes:
              # Actual horizontal scaling setup: point /data/git-bridge at a dedicated local ssd.
              - ~/git_bridge_data:/data/git-bridge
          container_name: git-bridge
          environment:
              GIT_BRIDGE_API_BASE_URL: "http://server-pro-ha-1/api/v0"
              GIT_BRIDGE_OAUTH2_SERVER: "http://server-pro-ha-1"
              GIT_BRIDGE_POSTBACK_BASE_URL: "http://198.18.0.6:8000"
              GIT_BRIDGE_ROOT_DIR: "/data/git-bridge"
          user: root
          command: ["/server-pro-start.sh"]

          # Actual horizontal scaling setup: run on host 198.18.0.6 and expose port
          # ports:
          #     - "8000:8000"
          networks:
              default:
                  ipv4_address: 198.18.0.6

      # Actual horizontal scaling setup: run this container on a separate host.
      server-pro-ha-1: &server-pro-ha-config
          restart: always
          image: quay.io/sharelatex/sharelatex-pro:4.0.1
          container_name: server-pro-ha-1
          hostname: server-pro-ha-1
          depends_on:
              # Actual horizontal scaling setup: keep this entry.
              git-bridge:
                  condition: service_started

              # Actual horizontal scaling setup: remove the ones below as they run on other hosts.
              mongo:
                  condition: service_healthy
              redis:
                  condition: service_started
              minio:
                  condition: service_started
              mongo_replica_set_setup:
                  condition: service_completed_successfully
              minio_setup:
                  condition: service_completed_successfully
          stop_grace_period: 60s
          volumes:
              - /tmp/scratch-disk1:/var/lib/sharelatex
              - /var/run/docker.sock:/var/run/docker.sock
          environment: &server-pro-ha-environment
              # Actual horizontal scaling setup: provide your own domain/app name.
              OVERLEAF_SITE_URL: 'https://overleaf.example.com'
              OVERLEAF_APP_NAME: Server Pro Horizontal Scaling Demo

              OVERLEAF_MONGO_URL: mongodb://198.18.0.3/sharelatex
              OVERLEAF_REDIS_HOST: 198.18.0.4
              REDIS_HOST: 198.18.0.4

              ENABLED_LINKED_FILE_TYPES: 'project_file,project_output_file'
              EMAIL_CONFIRMATION_DISABLED: 'true'

              SANDBOXED_COMPILES: 'true'
              SANDBOXED_COMPILES_SIBLING_CONTAINERS: 'true'
              SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk1/data/compiles'

              # S3
              # Actual horizontal scaling setup: pick secure credentials.
              OVERLEAF_FILESTORE_BACKEND: s3
              OVERLEAF_FILESTORE_USER_FILES_BUCKET_NAME: overleaf-user-files
              OVERLEAF_FILESTORE_TEMPLATE_FILES_BUCKET_NAME: overleaf-template-files
              OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID: OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID
              OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY: OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY
              OVERLEAF_FILESTORE_S3_ENDPOINT: http://198.18.0.5:9000
              OVERLEAF_FILESTORE_S3_PATH_STYLE: 'true'
              OVERLEAF_FILESTORE_S3_REGION: ''

              OVERLEAF_HISTORY_BACKEND: "s3"
              OVERLEAF_HISTORY_PROJECT_BLOBS_BUCKET: "overleaf-project-blobs"
              OVERLEAF_HISTORY_CHUNKS_BUCKET: "overleaf-chunks"
              OVERLEAF_HISTORY_S3_ACCESS_KEY_ID: "OVERLEAF_HISTORY_S3_ACCESS_KEY_ID"
              OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY: "OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY"
              OVERLEAF_HISTORY_S3_ENDPOINT: http://198.18.0.5:9000
              OVERLEAF_HISTORY_S3_PATH_STYLE: 'true'
              OVERLEAF_HISTORY_S3_REGION: ''
              # /S3

              # git-bridge
              GIT_BRIDGE_ENABLED: 'true'
              GIT_BRIDGE_HOST: 198.18.0.6
              GIT_BRIDGE_PORT: 8000
              # Only needed on the sibling instance of git-bridge
              V1_HISTORY_URL: "http://server-pro-ha-1:3100/api"
              # /git-bridge

              # Horizontal scaling
              # Actual horizontal scaling setup: pick secure credentials.
              WEB_API_PASSWORD: WEB_API_PASSWORD
              STAGING_PASSWORD: V1_HISTORY_PASSWORD
              V1_HISTORY_PASSWORD: V1_HISTORY_PASSWORD
              CRYPTO_RANDOM: CRYPTO_RANDOM
              OT_JWT_AUTH_KEY: OT_JWT_AUTH_KEY
              OVERLEAF_BEHIND_PROXY: 'true'
              # Actual horizontal scaling setup: IPs of load balancers
              TRUSTED_PROXY_IPS: 198.18.0.1,198.18.0.2
              # /Horizontal scaling

          # Actual horizontal scaling setup: run on host 198.18.1.1 and expose ports
          # ports:
          #     - "80:80"
          networks:
              default:
                  ipv4_address: 198.18.1.1

      # Actual horizontal scaling setup: run this container on a separate host.
      server-pro-ha-2:
          <<: *server-pro-ha-config
          hostname: server-pro-ha-2
          container_name: server-pro-ha-2
          volumes:
              - /tmp/scratch-disk2:/var/lib/sharelatex
              - /var/run/docker.sock:/var/run/docker.sock
          environment:
              <<: *server-pro-ha-environment
              SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk2/data/compiles'
              V1_HISTORY_URL: "http://localhost:3100/api"

          # Actual horizontal scaling setup: run on host 198.18.1.2 and expose ports
          # ports:
          #     - "80:80"
          networks:
              default:
                  ipv4_address: 198.18.1.2

      # Actual horizontal scaling setup: run this container on a separate host.
      server-pro-ha-3:
          <<: *server-pro-ha-config
          hostname: server-pro-ha-3
          container_name: server-pro-ha-3
          volumes:
              - /tmp/scratch-disk3:/var/lib/sharelatex
              - /var/run/docker.sock:/var/run/docker.sock
          environment:
              <<: *server-pro-ha-environment
              SANDBOXED_COMPILES_HOST_DIR: '/tmp/scratch-disk3/data/compiles'
              V1_HISTORY_URL: "http://localhost:3100/api"

          # Actual horizontal scaling setup: run on host 198.18.1.3 and expose ports
          # ports:
          #     - "80:80"
          networks:
              default:
                  ipv4_address: 198.18.1.3

      # Actual horizontal scaling setup: run this container on a separate host.
      minio:
          image: minio/minio:RELEASE.2023-05-18T00-05-36Z
          container_name: minio
          command: server /data
          volumes:
              # Actual horizontal scaling setup: run minio with multiple disks, see minio docs.
              - ~/minio_data:/data
          environment:
              # Actual horizontal scaling setup: pick secure credentials.
              MINIO_ROOT_USER: MINIO_ROOT_USER
              MINIO_ROOT_PASSWORD: MINIO_ROOT_PASSWORD

          # Actual horizontal scaling setup: run on host 198.18.0.5 and expose port
          # ports:
          #     - "9000:9000"
          networks:
              default:
                  ipv4_address: 198.18.0.5

      # Actual horizontal scaling setup: run this setup once on a separate host.
      minio_setup:
          depends_on:
              - minio
          image: minio/mc:RELEASE.2023-05-18T16-59-00Z
          entrypoint: sh
          command:
              - '-c'
              # Actual horizontal scaling setup: pick secure credentials.
              - |
                  mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \
                  || sleep 10 && \
                  mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \
                  || sleep 10 && \
                  mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD \
                  || sleep 10 && \
                  mc alias set s3 http://198.18.0.5:9000 MINIO_ROOT_USER MINIO_ROOT_PASSWORD

                  mc mb --ignore-existing s3/overleaf-user-files
                  mc mb --ignore-existing s3/overleaf-template-files
                  mc admin user add s3 \
                    OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID \
                    OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY

                  mc mb --ignore-existing s3/overleaf-project-blobs
                  mc mb --ignore-existing s3/overleaf-chunks
                  mc admin user add s3 \
                    OVERLEAF_HISTORY_S3_ACCESS_KEY_ID \
                    OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY

                  echo '
                    {
                      "Version": "2012-10-17",
                      "Statement": [
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:ListBucket"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-user-files"
                        },
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:PutObject",
                            "s3:GetObject",
                            "s3:DeleteObject"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-user-files/*"
                        },
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:ListBucket"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-template-files"
                        },
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:PutObject",
                            "s3:GetObject",
                            "s3:DeleteObject"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-template-files/*"
                        }
                      ]
                    }' > policy-filestore.json

                  echo '
                    {
                      "Version": "2012-10-17",
                      "Statement": [
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:ListBucket"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-project-blobs"
                        },
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:PutObject",
                            "s3:GetObject",
                            "s3:DeleteObject"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-project-blobs/*"
                        },
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:ListBucket"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-chunks"
                        },
                        {
                          "Effect": "Allow",
                          "Action": [
                            "s3:PutObject",
                            "s3:GetObject",
                            "s3:DeleteObject"
                          ],
                          "Resource": "arn:aws:s3:::overleaf-chunks/*"
                        }
                      ]
                    }' > policy-history.json

                  # Put the contents of the policy from the previous section in policy-filestore.json
                  # Reminder: Replace the bucket names accordingly.
                  mc admin policy create s3 overleaf-filestore policy-filestore.json
                  mc admin policy attach s3 overleaf-filestore \
                    --user=OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID || true

                  mc admin policy create s3 overleaf-history policy-history.json
                  mc admin policy attach s3 overleaf-history \
                    --user=OVERLEAF_HISTORY_S3_ACCESS_KEY_ID || true

      # Actual horizontal scaling setup: run this container on a separate host.
      mongo:
          restart: always
          image: mongo:4.4
          container_name: mongo
          command: "--replSet overleaf"
          expose:
              - 27017
          volumes:
              - ~/mongo_data:/data/db
          healthcheck:
              test: echo 'db.stats().ok' | mongo localhost:27017/test --quiet
              interval: 10s
              timeout: 10s
              retries: 5

          # Actual horizontal scaling setup: run on host 198.18.0.3 and expose port
          # ports:
          #     - "27017:27017"
          networks:
              default:
                  ipv4_address: 198.18.0.3

      mongo_replica_set_setup:
          image: mongo:4.4
          entrypoint: sh
          depends_on:
              mongo:
                  condition: service_healthy
          command:
              - '-c'
              - |
                  mongo 198.18.0.3 --eval "rs.initiate({ _id: \"overleaf\", members: [ { _id: 0, host: \"198.18.0.3:27017\" } ] })"

      # Actual horizontal scaling setup: run this container on a separate host.
      redis:
          restart: always
          image: redis:6.2
          container_name: redis
          expose:
              - 6379
          volumes:
              - ~/redis_data:/data

          # Actual horizontal scaling setup: run on host 198.18.0.4 and expose port
          # ports:
          #     - "6379:6379"
          networks:
              default:
                  ipv4_address: 198.18.0.4
  ```
</Accordion>

#### 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](/pt/on-premises/getting-started/requirements/hardware-requirements) 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](/pt/on-premises/maintenance/data-and-backups#performing-a-consistent-backup)
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


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.