> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/on-premises/pt/comecar/microservices.md). # Microserviços A forma recomendada de implementar e gerir instâncias do Overleaf Server CE e do Overleaf Pro é através da utilização do Toolkit. O Toolkit simplifica a criação da sua instância do Overleaf através da utilização de alguns scripts personalizados que abstraem a orquestração dos microsserviços necessários. Basta executar o script de inicialização incluído, fornecer algumas opções de configuração, como os caminhos do seu armazenamento persistente, e o Toolkit encarregar-se-á de aprovisionar e ligar os microsserviços que compõem a sua instância do Overleaf Server CE ou Pro. Isto deixa-o livre para se concentrar na personalização da experiência do utilizador e na implementação das funcionalidades específicas que compõem a sua instância local. O Toolkit trata de toda a complexidade nos bastidores, permitindo uma implementação simplificada da sua instância do Overleaf. {% hint style="info" %} Por razões de legado, o contentor principal do Overleaf chama-se `sharelatex`, e baseia-se na `sharelatex/sharelatex` imagem Docker. Isto acontece porque a tecnologia assenta na base de código do ShareLaTeX, que foi incorporada no Overleaf. Consulte [este artigo do blogarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) para mais detalhes. Em algum momento no futuro, isto será renomeado para corresponder ao esquema de nomenclatura do Overleaf. {% endhint %} #### Arquitetura No interior do contentor do Overleaf, o software é executado como um conjunto de microsserviços, gerido por `runit`. Alguns dos ficheiros mais interessantes no interior do contentor são: * `/etc/service/`: ficheiros de inicialização para os microsserviços. * `/var/log/overleaf/`: registos de cada microsserviço. * `/overleaf/services/`: código para os vários microsserviços. * `/var/lib/overleaf/`: o ponto de montagem para os dados persistentes (corresponde ao diretório indicado por `OVERLEAF_DATA_PATH` no anfitrião). #### Os Contentores MongoDB e Redis O Overleaf depende de duas bases de dados externas: MongoDB e Redis. Por predefinição, o Toolkit irá aprovisionar um contentor para cada uma destas bases de dados, além do contentor do Overleaf, num total de três contentores Docker. {% hint style="info" %} Se preferir ligar-se a uma instância existente do MongoDB ou do Redis, pode fazê-lo definindo as definições apropriadas no [overleaf.rc](https://overleaf-pro.ayaka.space/on-premises/pt/comecar/pages/4760787dada763da663d7c17eb8bfe49f1de3448#the-overleaf.rc-file) ficheiro de configuração. {% endhint %} #### Editor e processo de compilação Esta secção fornece uma visão geral ampla do tratamento dos documentos e do processo de compilação. {% hint style="info" %} Esta página descreve o processo de compilação com Compilações em sandbox, disponível apenas no Overleaf Pro. No Server CE, o processo de compilação usa subprocessos simples — substitua os itens que fazem referência a um **contentor** por um único item **executar compilação em subprocesso**. {% endhint %} Componentes / Atores: * `utilizador` — Um utilizador da aplicação * `editor` — A aplicação cliente em execução no navegador * `clsi` — O microsserviço usado para compilar PDFs * `document-updater` — O microsserviço usado para processar atualizações de documentos * `filestore` — O microsserviço que trata ficheiros binários * `real-time` — O microsserviço usado para tratar websockets * `web` — O (nem tão) microsserviço usado para tratar pedidos de API **Cache do Redis** * **utilizador**: carrega a página do editor * **editor**: abre websocket * **editor**: envia pedido para abrir um documento via websocket * **real-time** -> **document-updater**: o documento é carregado do MongoDB para o Redis * **editor**: envia atualização do documento via websocket * **real-time** -> **document-updater**: o documento é atualizado no Redis * **editor**: envia mais pedidos de compilação * Após terem passado 5 minutos desde a última descarga (por documento): * **document-updater**: descarrega o documento do Redis para o MongoDB * **editor**: envia mais atualizações * a cada 100 atualizações (por documento): * **document-updater**: descarrega o histórico do documento do Redis para o MongoDB * **utilizador**: sai do editor/fecha o separador do navegador * 5 minutos depois * **real-time**: verifica se há outros colaboradores; se não houver: * **real-time** -> **document-updater**: descarrega documentos do Redis para o MongoDB **Leitura do MongoDB para o Redis** * **document-updater** -> **web** -> **docstore**: ler do MongoDB **Descarga do Redis para o MongoDB** * **document-updater** -> **web** -> **docstore**: escrever no MongoDB **Compilação — modo de sincronização "completo"** * **editor**: envia pedido de compilação com o modo de sincronização definido para "completo" * **web** -> **document-updater**: quaisquer documentos são descarregados do Redis para o MongoDB * **web** -> **docstore**: todos os documentos são descarregados do MongoDB * **web** -> **clsi**: o pedido de compilação é enviado para `clsi`, incluindo: * o modo de sincronização * um hash da árvore de ficheiros -> o "estado do projeto" * todos os documentos com o seu conteúdo -> sujeito ao limite de 7 MB no corpo do pedido * URLs dos ficheiros binários para descarregamento separado * **clsi**: verifica o estado em disco com o modo de sincronização e o "estado do projeto" * isto é uma sincronização completa, portanto o estado anterior em disco pode ser ignorado * **clsi**: limpa o diretório de compilação * **clsi**: escreve todos os documentos no diretório de compilação * **clsi**: escreve todos os ficheiros binários no diretório de compilação * `clsi` copia os ficheiros de uma cache local por projeto * em caso de falha na cache: * **clsi** -> **filestore**: descarrega ficheiros * **clsi**: escreve o "estado do projeto" * **clsi**: garante que o contentor Docker existe com a configuração desejada * constrói as opções do contentor, incluindo a versão do texlive * opções de hash * nome do contentor: `project---` * **clsi**: inicia o contentor e transmite stdout/stderr para a memória -> limite de 2 MB * **clsi**: deixa o contentor parado -> removido após 24 h * **clsi**: escreve stdout/stderr no disco * **clsi**: copia os ficheiros de saída para um diretório de saída único * id de compilação composto por 8 bytes aleatórios mais carimbo de data/hora com precisão em ms * elimina todas as pastas de compilação, exceto as últimas 3 (anónimo) / a última 1 (utilizador com sessão iniciada) * **clsi**: a compilação falhou/atingiu o tempo limite * elimina a cache de compilação — pode conter ficheiros parciais/cache corrompida * **editor**: descarrega output.log e output.pdf **Compilação — modo de sincronização "incremental"** * **editor**: envia pedido de compilação com o modo de sincronização definido para "incremental" * **web** -> **document-updater**: obtém quaisquer documentos do Redis * o hash do "estado do projeto" também é armazenado no Redis * **web** envia o hash da árvore de ficheiros para `document-updater` e `document-updater` pode transformar a compilação incremental numa compilação completa em caso de incompatibilidade * consulte o processo de compilação tal como realizado quando o editor pediu uma compilação "completa" * **web** -> **clsi**: o pedido de compilação é enviado para `clsi`, incluindo: * o modo de sincronização * um hash da árvore de ficheiros -> o "estado do projeto" * todos os documentos do Redis com o seu conteúdo -> sujeito ao limite de 7 MB no corpo do pedido * sem ficheiros binários * **clsi**: verifica o estado em disco com o modo de sincronização e o "estado do projeto" * isto é uma sincronização incremental, portanto o "estado do projeto" tem de coincidir * em caso de incompatibilidade: responder com 409, permitir que a web volte a tentar com sincronização "completa" * consulte o processo de compilação tal como realizado quando o editor pediu uma compilação "completa" * **clsi**: escreve os documentos atualizados no diretório de compilação * **clsi**: garante que o contentor Docker existe com a configuração desejada * constrói as opções do contentor, incluindo a versão do texlive * opções de hash * nome do contentor: `project---` * **clsi**: inicia o contentor e transmite stdout/stderr para a memória -> limite de 2 MB * **clsi**: deixa o contentor parado -> removido após 24 h * **clsi**: escreve stdout/stderr no disco * **clsi**: copia os ficheiros de saída para um diretório de saída único * id de compilação composto por 8 bytes aleatórios mais carimbo de data/hora com precisão em ms * elimina todas as pastas de compilação, exceto as últimas 3 (anónimo) / a última 1 (utilizador com sessão iniciada) * **clsi**: a compilação falhou/atingiu o tempo limite * elimina a cache de compilação — pode conter ficheiros parciais/cache corrompida * **editor**: descarrega output.log e output.pdf **Compilação — alternar entre modos** * **editor**: observa uma falha de compilação, a próxima compilação é uma compilação "completa" * **editor**: observa uma compilação bem-sucedida, a próxima compilação é uma compilação "incremental" --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/on-premises/pt/comecar/microservices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.