> 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/sv/komma-igang/microservices.md). # Mikrotjänster Det rekommenderade sättet att distribuera och hantera Overleaf Server CE- och Overleaf Pro-instanser är att använda Toolkit. Toolkit förenklar skapandet av din Overleaf-instans genom att använda några anpassade skript som abstraherar bort orkestreringen av de mikrotjänster som krävs. Kör bara det medföljande initieringsskriptet, ange några konfigurationsalternativ som dina sökvägar för beständig lagring, så tar Toolkit hand om provisioneringen och anslutningen av de mikrotjänster som utgör din Overleaf Server CE- eller Pro-instans. Detta gör att du kan fokusera på att anpassa användarupplevelsen och implementera de specifika funktioner som utgör din lokala instans. Toolkit hanterar all komplexitet bakom kulisserna och möjliggör en förenklad distribution av din Overleaf-instans. {% hint style="info" %} Av kompatibilitetsskäl kallas den huvudsakliga Overleaf-containern `sharelatex`, och bygger på `sharelatex/sharelatex` Docker-avbildningen. Detta beror på att tekniken bygger på ShareLaTeX-kodbasen, som slogs samman med Overleaf. Se [detta blogginläggarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) för mer information. Vid någon tidpunkt i framtiden kommer detta att byta namn så att det matchar Overleafs namngivningsschema. {% endhint %} #### Arkitektur Inuti Overleaf-containern körs programvaran som en uppsättning mikrotjänster, hanterade av `runit`. Några av de mer intressanta filerna inuti containern är: * `/etc/service/`: initieringsfiler för mikrotjänsterna. * `/var/log/overleaf/`: loggar för varje mikrotjänst. * `/overleaf/services/`: kod för de olika mikrotjänsterna. * `/var/lib/overleaf/`: monteringspunkten för beständiga data (motsvarar katalogen som anges av `OVERLEAF_DATA_PATH` på värden). #### MongoDB- och Redis-containrarna Overleaf är beroende av två externa databaser: MongoDB och Redis. Som standard kommer Toolkit att skapa en container för var och en av dessa databaser, utöver Overleaf-containern, vilket ger totalt tre Docker-containrar. {% hint style="info" %} Om du föredrar att ansluta till en befintlig MongoDB- eller Redis-instans kan du göra det genom att ange lämpliga inställningar i [overleaf.rc](https://ayakaleaf-pro.ayaka.space/on-premises/sv/komma-igang/pages/98ffddbccb4995b2a3c5d2e4fb126808e79dcab6#the-overleaf.rc-file) konfigurationsfilen. {% endhint %} #### Redigerings- och kompileringsprocess Detta avsnitt ger en övergripande översikt över hanteringen av dokument och kompileringsprocessen. {% hint style="info" %} Denna sida beskriver kompileringsprocessen med Sandboxed Compiles, som endast finns i Overleaf Pro. I Server CE använder kompileringsprocessen enkla underprocesser — ersätt objekten som hänvisar till en **containern** med ett enda objekt **kör kompilering i underprocess**. {% endhint %} Komponenter / aktörer: * `användare` — En användare av applikationen * `redigerare` — Klientapplikationen som körs i webbläsaren * `clsi` — Mikrotjänsten som används för att kompilera PDF-filer * `document-updater` — Mikrotjänsten som används för att bearbeta dokumentuppdateringar * `filestore` — Mikrotjänsten som hanterar binära filer * `real-time` — Mikrotjänsten som används för att hantera websocketar * `web` — Den (inte så) mikrotjänsten som används för att hantera API-förfrågningar **Redis-cachelagring** * **användare**: laddar redigeringssidan * **redigerare**: öppnar en websocket * **redigerare**: skickar en begäran om att öppna ett dokument via websocket * **real-time** -> **document-updater**: dokumentet läses in från MongoDB till Redis * **redigerare**: skickar dokumentuppdatering via websocket * **real-time** -> **document-updater**: dokumentet uppdateras i Redis * **redigerare**: skickar fler kompileringsbegäranden * När 5 minuter har gått sedan senaste tömningen (per dokument): * **document-updater**: töm dokumentet från Redis till MongoDB * **redigerare**: skickar fler uppdateringar * var 100:e uppdatering (per dokument): * **document-updater**: töm dokumenthistoriken från Redis till MongoDB * **användare**: lämnar redigeraren/stänger webbläsarfliken * 5 minuter senare * **real-time**: kontrollerar om det finns andra medarbetare, om det inte finns några: * **real-time** -> **document-updater**: tömmer dokument från Redis till MongoDB **Läser från MongoDB in i Redis** * **document-updater** -> **web** -> **docstore**: läs från MongoDB **Tömning från Redis till MongoDB** * **document-updater** -> **web** -> **docstore**: skriv till MongoDB **Kompilering — synkroniseringsläget "full"** * **redigerare**: skickar kompileringsbegäran med synkroniseringsläget satt till "full" * **web** -> **document-updater**: eventuella dokument töms från Redis till MongoDB * **web** -> **docstore**: alla dokument hämtas ner från MongoDB * **web** -> **clsi**: kompileringsbegäran skickas till `clsi`, inklusive: * synkroniseringsläget * en hash av filträdet -> "projekttillståndet" * alla dokument med deras innehåll -> omfattas av gränsen på 7 MB för begärans brödtext * URL:er för binära filer för separat nedladdning * **clsi**: kontrollera tillståndet på disk med synkroniseringsläget och "projekttillståndet" * detta är en fullständig synkronisering, så tidigare tillstånd på disk kan ignoreras * **clsi**: städa upp kompileringskatalogen * **clsi**: skriv alla dokument till kompileringskatalogen * **clsi**: skriv alla binära filer till kompileringskatalogen * `clsi` kopierar filerna från en lokal cache per projekt * vid cachemiss: * **clsi** -> **filestore**: ladda ner filer * **clsi**: skriv "projekttillståndet" * **clsi**: säkerställ att Docker-containern finns med önskad konfiguration * bygg containeralternativ, inklusive TeX Live-version * hasha alternativ * containernamn: `project---` * **clsi**: starta containern och strömma stdout/stderr till minnet -> gräns 2 MB * **clsi**: lämna kvar stoppad container -> städas upp efter 24 h * **clsi**: skriv stdout/stderr till disk * **clsi**: kopiera utdatafiler till en unik utdatakatalog * build-id består av 8 slumpmässiga byte plus en tidsstämpel med ms-precision * ta bort alla utom de senaste 3 (anonyma) / senaste 1 (inloggad användare) buildmapparna * **clsi**: kompileringen misslyckades/tidsgränsen överskreds * ta bort kompileringscachen — den kan innehålla delvisa filer/korrupt cache * **redigerare**: laddar ner output.log och output.pdf **Kompilering — synkroniseringsläget "inkrementellt"** * **redigerare**: skickar kompileringsbegäran med synkroniseringsläget satt till "inkrementellt" * **web** -> **document-updater**: hämta eventuella dokument från Redis * hashen för "projekttillståndet" lagras också i Redis * **web** skickar hashvärdet för filträdet till `document-updater` och `document-updater` kan göra om den inkrementella kompileringen till en fullständig kompilering vid avvikelse * se kompileringsprocessen som den utförs när redigeraren begärde "full" kompilering * **web** -> **clsi**: kompileringsbegäran skickas till `clsi`, inklusive: * synkroniseringsläget * en hash av filträdet -> "projekttillståndet" * alla dokument från Redis med deras innehåll -> omfattas av gränsen på 7 MB för begärans brödtext * inga binära filer * **clsi**: kontrollera tillståndet på disk med synkroniseringsläget och "projekttillståndet" * detta är en inkrementell synkronisering, så "projekttillståndet" måste stämma överens * vid avvikelse: svara med 409, låt webben försöka igen med "full" synkning * se kompileringsprocessen som den utförs när redigeraren begärde "full" kompilering * **clsi**: skriv uppdaterade dokument till kompileringskatalogen * **clsi**: säkerställ att Docker-containern finns med önskad konfiguration * bygg containeralternativ, inklusive TeX Live-version * hasha alternativ * containernamn: `project---` * **clsi**: starta containern och strömma stdout/stderr till minnet -> gräns 2 MB * **clsi**: lämna kvar stoppad container -> städas upp efter 24 h * **clsi**: skriv stdout/stderr till disk * **clsi**: kopiera utdatafiler till en unik utdatakatalog * build-id består av 8 slumpmässiga byte plus en tidsstämpel med ms-precision * ta bort alla utom de senaste 3 (anonyma) / senaste 1 (inloggad användare) buildmapparna * **clsi**: kompileringen misslyckades/tidsgränsen överskreds * ta bort kompileringscachen — den kan innehålla delvisa filer/korrupt cache * **redigerare**: laddar ner output.log och output.pdf **Kompilering — växling mellan lägen** * **redigerare**: observerar ett kompileringsfel, nästa kompilering är en "full" kompilering * **redigerare**: observerar en lyckad kompilering, nästa kompilering är en "inkrementell" kompilering --- # 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/sv/komma-igang/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.