1
Armazenamento S3
Configure os três buckets e os dois usuários conforme descrito em S3, com o seu serviço S3 ou com o Garage no cluster, e coloque as quatro chaves no Secret
overleaf-s3. A configuração abaixo usa o exemplo do Garage daquela página.2
Configuração
Este ConfigMap substitui
30-config.yaml. Ele adiciona o S3 e o git-bridge e aponta OVERLEAF_SITE_URL para o balanceador de carga:60-config.yaml
3
Réplicas
70-overleaf.yaml
- StatefulSet, não Deployment. Cada réplica recebe um nome estável (
overleaf-0,overleaf-1, …) ao qual o cookie do balanceador de carga e o git-bridge se referem, eOrderedReadyinicia primeiro apenasoverleaf-0, de modo que somente uma réplica executa as migrações do banco de dados. - Uma réplica por nó. Cada réplica inicia suas compilações pelo Docker do seu nó e as mantém em
/srv/overleaf-hado seu nó. V1_HISTORY_URLpor réplica. Cada réplica fornece links de histórico com seu próprio nome, para que o git-bridge possa alcançá-los.
4
git-bridge
75-git-bridge.yaml
GIT_BRIDGE_HOST é um endereço IP fixo.5
Balanceador de carga
A configuração do HAProxy é o exemplo do Overleaf com cinco alterações:
/project/<id>/mcp roteado para overleaf-0 como /git/ (consulte Servidor MCP), HTTP simples na porta 8080 (a imagem é executada como um usuário não root, que não pode usar a porta 80 sob o containerd), servidores encontrados pelo DNS do cluster (os IPs dos pods mudam a cada reinicialização), um DaemonSet para que todos os nós respondam e balance leastconn em vez do padrão roundrobin (consulte o Q&A abaixo).80-haproxy.yaml
externalTrafficPolicy: Local mantém os endereços IP dos usuários em X-Forwarded-For.6
TLS
Termine o HTTPS no HAProxy conforme descrito em Proxy TLS e, em seguida, defina
OVERLEAF_SITE_URL com o endereço https:// e OVERLEAF_SECURE_COOKIE: "true" em 60-config.yaml.O que esperar
Testamos três réplicas em três nós com 2 vCPUs e 4 GB cada, com MongoDB, Redis, Garage, git-bridge e HAProxy nos mesmos nós:- 12 usuários compilando um documento de 600 páginas ao mesmo tempo: todos os 12 compilaram e obtiveram seu PDF, 4 usuários por réplica; uma rodada levou de 8 a 18 segundos. Cada nó manteve pelo menos 1,3 GB de memória disponível.
- Cada usuário permanece em uma réplica (cookie
server-pro-ha), incluindo o download do PDF, que precisa vir da réplica que o compilou. O mesmo vale via HTTPS, incluindo o WebSocket do editor. - Quando uma réplica para, seus usuários recebem erros por cerca de 15 a 20 segundos, até que o HAProxy a marque como fora do ar; então eles passam para outra réplica e permanecem conectados, porque as sessões ficam no Redis.
Q&A
Por que balance leastconn?
Por que balance leastconn?
Resposta: Com o exemplo do Overleaf (
roundrobin, um HAProxy por nó), 12 novos usuários ficaram distribuídos em 8, 3 e 1 nas três réplicas no nosso teste, e a réplica mais ocupada fez os usuários mais lentos esperarem 29 segundos. Com leastconn, que prefere a réplica com menos conexões abertas (cada editor mantém um WebSocket aberto), o mesmo teste resultou em 4, 4 e 4 e 18 segundos. A persistência de sessão não muda: ela vem do cookie.Posso usar meu ingress controller em vez do HAProxy?
Posso usar meu ingress controller em vez do HAProxy?
Resposta: Sim, se ele rotear por um cookie para uma réplica estável, suportar WebSockets, permitir tempos de requisição de 10 minutos e uploads de 50 MB, mantiver seu timeout de keep-alive abaixo de 65 segundos, enviar
X-Forwarded-For e X-Forwarded-Proto e enviar /git/ e /project/<id>/mcp para overleaf-0. Roteie para os nomes próprios das réplicas (overleaf-N.overleaf-hl), não para um Service que balanceia cada requisição.Como adiciono uma quarta réplica?
Como adiciono uma quarta réplica?
Resposta: Adicione um nó com Docker e as imagens do TeX Live, defina
replicas: 4 em 70-overleaf.yaml e adicione uma linha server overleaf-3 ... à configuração do HAProxy (e incremente config-hash para que o HAProxy reinicie).
