> For the complete documentation index, see [llms.txt](https://ayakaleaf-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://ayakaleaf-pro.ayaka.space/on-premises/pt/primeiros-passos/microservices.md). # Microsserviç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 do uso 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 de armazenamento persistente, e o Toolkit tratará do aprovisionamento e da ligação dos microsserviços que compõem a sua instância do Overleaf Server CE ou Pro. Isto permite-lhe concentrar-se 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 históricas, o contentor principal do Overleaf chama-se `sharelatex`, e baseia-se na `sharelatex/sharelatex` imagem Docker. Isto porque a tecnologia assenta na base de código do ShareLaTeX, que foi incorporada no Overleaf. Consulte [esta publicação do blogue seta para cima e para a direita](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 nomes do Overleaf. {% endhint %} #### Arquitetura Dentro do contentor do Overleaf, o software é executado como um conjunto de microsserviços, geridos por `runit`. Alguns dos ficheiros mais interessantes dentro 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 dos 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 do MongoDB e do Redis O Overleaf depende de duas bases de dados externas: MongoDB e Redis. Por predefinição, o Toolkit 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 opções apropriadas no [overleaf.rc](https://ayakaleaf-pro.ayaka.space/on-premises/pt/primeiros-passos/pages/4760787dada763da663d7c17eb8bfe49f1de3448#the-overleaf.rc-file) ficheiro de configuração. {% endhint %} #### Processo de edição e compilação Esta secção fornece uma visão geral ampla do tratamento de 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 utiliza subprocessos simples — substitua os itens que fazem referência a um **container** 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 utilizado para compilar PDFs * `document-updater` — O microsserviço utilizado para processar atualizações de documentos * `filestore` — O microsserviço que lida com ficheiros binários * `real-time` — O microsserviço utilizado para lidar com web sockets * `web` — O microsserviço (não tão) micro utilizado para lidar com pedidos de API **Cache do Redis** * **utilizador**: carrega a página do editor * **editor**: abre o web socket * **editor**: envia um pedido para abrir um documento via web socket * **real-time** -> **document-updater**: o documento é carregado do MongoDB para o Redis * **editor**: envia atualização do documento via web socket * **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 escrita para disco (por documento): * **document-updater**: escreve o documento do Redis para o MongoDB * **editor**: envia mais atualizações * a cada 100 atualizações (por documento): * **document-updater**: escreve 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**: escreve os documentos do Redis para o MongoDB **Leitura do MongoDB para o Redis** * **document-updater** -> **web** -> **docstore**: lê do MongoDB **Escrita do Redis para o MongoDB** * **document-updater** -> **web** -> **docstore**: escreve no MongoDB **Compilação — modo de sincronização "total"** * **editor**: envia um pedido de compilação com o modo de sincronização definido como "total" * **web** -> **document-updater**: quaisquer documentos são escritos 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 do corpo do pedido * URLs de ficheiros binários para descarregamento separado * **clsi**: verifica o estado em disco com o modo de sincronização e o "estado do projeto" * esta é uma sincronização total, pelo que 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 os ficheiros * **clsi**: escreve o "estado do projeto" * **clsi**: garante que o contentor Docker existe com a configuração desejada * opções do contentor de compilação, inclui 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 para trás -> é limpo após 24h * **clsi**: escreve stdout/stderr para 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 timestamp com precisão de milissegundos * elimina todas as pastas de compilação, exceto as últimas 3 (anónimo) / última 1 (utilizador autenticado) * **clsi**: a compilação falhou/atingiu o tempo limite * elimina a cache de compilação — pode ter ficheiros parciais/cache corrompida * **editor**: descarrega output.log e output.pdf **Compilação — modo de sincronização "incremental"** * **editor**: envia um pedido de compilação com o modo de sincronização definido como "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 total em caso de discrepância * ver o processo de compilação tal como é efetuado quando o editor solicitou compilação "total" * **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 do corpo do pedido * sem ficheiros binários * **clsi**: verifica o estado em disco com o modo de sincronização e o "estado do projeto" * esta é uma sincronização incremental, pelo que o "estado do projeto" tem de corresponder * em caso de discrepância: responde com 409, permite que a web tente novamente com sincronização "total" * ver o processo de compilação tal como é efetuado quando o editor solicitou compilação "total" * **clsi**: escreve os documentos atualizados no diretório de compilação * **clsi**: garante que o contentor Docker existe com a configuração desejada * opções do contentor de compilação, inclui 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 para trás -> é limpo após 24h * **clsi**: escreve stdout/stderr para 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 timestamp com precisão de milissegundos * elimina todas as pastas de compilação, exceto as últimas 3 (anónimo) / última 1 (utilizador autenticado) * **clsi**: a compilação falhou/atingiu o tempo limite * elimina a cache de compilação — pode ter 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 "total" * **editor**: observa um sucesso de compilação, 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://ayakaleaf-pro.ayaka.space/on-premises/pt/primeiros-passos/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.