> 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/sv/kom-igang/microservices.md). # Mikrotjänster Det rekommenderade sättet att driftsätta och hantera instanser av Overleaf Server CE och Overleaf Pro ä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, och Toolkit kommer att sköta 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 i bakgrunden, vilket möjliggör en förenklad driftsättning av din Overleaf-instans. {% hint style="info" %} Av historiska skäl kallas den huvudsakliga Overleaf-containern `sharelatex`, och bygger på `sharelatex/sharelatex` Docker-avbilden. 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 punkt i framtiden kommer detta att döpas om så att det följer Overleafs namngivningsschema. {% endhint %} #### Arkitektur Inne i Overleaf-containern körs programvaran som en uppsättning mikrotjänster, som hanteras av `runit`. Några av de mer intressanta filerna i 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ärdsystemet). #### MongoDB- och Redis-containrarna Overleaf är beroende av två externa databaser: MongoDB och Redis. Som standard kommer Toolkit att tillhandahålla 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 hellre vill ansluta till en befintlig MongoDB- eller Redis-instans kan du göra det genom att ange lämpliga inställningar i [overleaf.rc](https://overleaf-pro.ayaka.space/on-premises/sv/kom-igang/pages/98ffddbccb4995b2a3c5d2e4fb126808e79dcab6#the-overleaf.rc-file) konfigurationsfilen. {% endhint %} #### Redigerare och kompileringsprocess Detta avsnitt ger en översikt över hanteringen av dokument och kompileringsprocessen. {% hint style="info" %} Den här sidan 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ärfiler * `real-time` — Mikrotjänsten som används för att hantera webbsocketar * `web` — Den (inte så) mikrotjänsten som används för att hantera API-förfrågningar **Redis-cachning** * **användare**: laddar redigerarsidan * **redigerare**: öppnar webbsocket * **redigerare**: skickar en begäran om att öppna ett dokument via webbsocket * **real-time** -> **document-updater**: dokumentet laddas från MongoDB till Redis * **redigerare**: skickar en dokumentuppdatering via webbsocket * **real-time** -> **document-updater**: dokumentet uppdateras i Redis * **redigerare**: skickar fler kompileringsbegäranden * Efter att 5 minuter har gått sedan senaste flushen (per dokument): * **document-updater**: flushar dokumentet från Redis till MongoDB * **redigerare**: skickar fler uppdateringar * efter varje 100 uppdateringar (per dokument): * **document-updater**: flushar 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**: flushar dokumenten från Redis till MongoDB **Läsning från MongoDB till Redis** * **document-updater** -> **web** -> **docstore**: läser från MongoDB **Spolning från Redis till MongoDB** * **document-updater** -> **web** -> **docstore**: skriver till MongoDB **Kompilering — synkläge "full"** * **redigerare**: skickar kompileringsbegäran med synkläge inställt på "full" * **web** -> **document-updater**: eventuella dokument spolas från Redis till MongoDB * **web** -> **docstore**: alla dokument hämtas från MongoDB * **web** -> **clsi**: kompileringsbegäran skickas till `clsi`, inklusive: * synkläget * en hash av filträdet -> "projekttillståndet" * alla dokument med deras innehåll -> begränsat av 7 MB-gränsen för begärans brödtext * URL:er för binärfiler för separat nedladdning * **clsi**: kontrollera tillståndet på disk mot synklä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ärfiler 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 alternativen * container-namn: `project---` * **clsi**: starta containern och strömma stdout/stderr till minnet -> gräns 2 MB * **clsi**: lämna den stoppade containern kvar -> städas upp efter 24 timmar * **clsi**: skriv stdout/stderr till disk * **clsi**: kopiera utdatafiler till en unik utdatakatalog * build-id består av 8 slumpmässiga byte plus tidsstämpel med millisekundprecision * ta bort alla utom de senaste 3 (anonyma) / senaste 1 (inloggad användare) byggmapparna * **clsi**: kompileringen misslyckades/tidsgränsen överskreds * ta bort kompileringscachen — den kan innehålla ofullständiga filer/skadad cache * **redigerare**: laddar ner output.log och output.pdf **Kompilering — inkrementellt synkläge** * **redigerare**: skickar kompileringsbegäran med synkläge inställt på "incremental" * **web** -> **document-updater**: hämta eventuella dokument från Redis * "projekttillståndets" hash lagras också i Redis * **web** skickar hashvärdet av filträdet till `document-updater` och `document-updater` kan göra om inkrementell kompilering till en fullständig kompilering vid avvikelse * se kompileringsprocessen som utförs när redigeraren begärde "full" kompilering * **web** -> **clsi**: kompileringsbegäran skickas till `clsi`, inklusive: * synkläget * en hash av filträdet -> "projekttillståndet" * alla dokument från Redis med deras innehåll -> begränsat av 7 MB-gränsen för begärans brödtext * inga binärfiler * **clsi**: kontrollera tillståndet på disk mot synkläget och "projekttillståndet" * detta är en inkrementell synkronisering, så "projekttillståndet" måste matcha * vid avvikelse: svara med 409, låt webben försöka igen med "full" synk * se kompileringsprocessen som 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 alternativen * container-namn: `project---` * **clsi**: starta containern och strömma stdout/stderr till minnet -> gräns 2 MB * **clsi**: lämna den stoppade containern kvar -> städas upp efter 24 timmar * **clsi**: skriv stdout/stderr till disk * **clsi**: kopiera utdatafiler till en unik utdatakatalog * build-id består av 8 slumpmässiga byte plus tidsstämpel med millisekundprecision * ta bort alla utom de senaste 3 (anonyma) / senaste 1 (inloggad användare) byggmapparna * **clsi**: kompileringen misslyckades/tidsgränsen överskreds * ta bort kompileringscachen — den kan innehålla ofullständiga filer/skadad 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://overleaf-pro.ayaka.space/on-premises/sv/kom-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.