> 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/da/kom-godt-i-gang/microservices.md). # Microservices Den anbefalede måde at implementere og administrere Overleaf Server CE- og Overleaf Pro-instanser på er via Toolkit. Toolkit forenkler oprettelsen af din Overleaf-instans gennem brugen af nogle tilpassede scripts, der abstraherer orkestreringen af de nødvendige mikrotjenester væk. Kør blot det medfølgende initialiseringsscript, angiv et par konfigurationsindstillinger som f.eks. dine stier til vedvarende lagring, og Toolkit sørger for at klargøre og forbinde de mikrotjenester, der udgør din Overleaf Server CE- eller Pro-instans. Det gør, at du kan fokusere på at tilpasse brugeroplevelsen og implementere de specifikke funktioner, der udgør din lokale instans. Toolkit håndterer al kompleksiteten bag kulisserne og muliggør en forenklet implementering af din Overleaf-instans. {% hint style="info" %} Af historiske årsager hedder den primære Overleaf-container `sharelatex`, og er baseret på `sharelatex/sharelatex` Docker-afbildningen. Det skyldes, at teknologien er baseret på ShareLaTeX-kodebasen, som blev flettet ind i Overleaf. Se [dette blogindlægarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) for flere detaljer. På et tidspunkt i fremtiden vil dette blive omdøbt, så det passer til Overleafs navngivningskonvention. {% endhint %} #### Arkitektur Inde i Overleaf-containeren kører softwaren som et sæt mikrotjenester, som administreres af `runit`. Nogle af de mere interessante filer inde i containeren er: * `/etc/service/`: initialiseringsfiler til mikrotjenesterne. * `/var/log/overleaf/`: logfiler for hver mikrotjeneste. * `/overleaf/services/`: kode til de forskellige mikrotjenester. * `/var/lib/overleaf/`: mountpunktet for vedvarende data (svarer til den mappe, der er angivet af `OVERLEAF_DATA_PATH` på værten). #### MongoDB- og Redis-containerne Overleaf er afhængig af to eksterne databaser: MongoDB og Redis. Som standard vil Toolkit klargøre en container til hver af disse databaser, ud over Overleaf-containeren, så der i alt er tre Docker-containere. {% hint style="info" %} Hvis du foretrækker at oprette forbindelse til en eksisterende MongoDB- eller Redis-instans, kan du gøre det ved at angive de relevante indstillinger i [overleaf.rc](https://overleaf-pro.ayaka.space/on-premises/da/kom-godt-i-gang/pages/901a5598670cbf8f8243fef240ca36c07d312cc4#the-overleaf.rc-file) konfigurationsfilen. {% endhint %} #### Editor- og kompileringsproces Dette afsnit giver et overordnet overblik over håndteringen af dokumenter og kompileringsprocessen. {% hint style="info" %} Denne side beskriver kompileringsprocessen med Sandboxed Compiles, som kun er tilgængelig i Overleaf Pro. I Server CE bruger kompileringsprocessen enkle underprocesser — erstat de elementer, der henviser til en **containeren** med et enkelt element **kør kompilering i underproces**. {% endhint %} Komponenter / aktører: * `bruger` — En bruger af applikationen * `editor` — Klientapplikationen, der kører i browseren * `clsi` — Mikrotjenesten, der bruges til at kompilere PDF'er * `document-updater` — Mikrotjenesten, der bruges til at behandle dokumentopdateringer * `filestore` — Mikrotjenesten, der håndterer binære filer * `real-time` — Mikrotjenesten, der håndterer websockets * `web` — Den ikke så mikro-mikrotjeneste, der bruges til at håndtere API-anmodninger **Redis-caching** * **bruger**: indlæser editorsiden * **editor**: åbner WebSocket-forbindelse * **editor**: sender en anmodning om at åbne et dokument via WebSocket * **real-time** -> **document-updater**: dokumentet indlæses fra MongoDB til Redis * **editor**: sender dokumentopdatering via WebSocket * **real-time** -> **document-updater**: dokumentet opdateres i Redis * **editor**: sender flere kompileringsanmodninger * Når der er gået 5 minutter siden sidste flush (pr. dokument): * **document-updater**: skriv dokumentet fra Redis til MongoDB * **editor**: sender flere opdateringer * for hver 100 opdateringer (pr. dokument): * **document-updater**: skriv dokumenthistorikken fra Redis til MongoDB * **bruger**: forlader editoren/lukker browserfanen * 5 minutter senere * **real-time**: tjekker for andre samarbejdspartnere, og hvis der ikke er nogen: * **real-time** -> **document-updater**: skriver dokumenter fra Redis til MongoDB **Læser fra MongoDB til Redis** * **document-updater** -> **web** -> **docstore**: læs fra MongoDB **Skriver fra Redis til MongoDB** * **document-updater** -> **web** -> **docstore**: skriv til MongoDB **Kompilering — "fuld" synkroniseringstilstand** * **editor**: sender kompilationsanmodning med synkroniseringstilstand sat til "fuld" * **web** -> **document-updater**: eventuelle dokumenter skrives fra Redis til MongoDB * **web** -> **docstore**: alle dokumenter downloades fra MongoDB * **web** -> **clsi**: kompilationsanmodning sendes til `clsi`, inklusive: * synkroniseringstilstanden * en hash af filtræet -> "projekttilstanden" * alle dokumenter med deres indhold -> underlagt en grænse på 7 MB for anmodningens brødtekst * URL'er til binære filer til separat download * **clsi**: tjek disktilstanden med synkroniseringstilstanden og "projekttilstanden" * dette er en fuld synkronisering, så den tidligere disktilstand kan ignoreres * **clsi**: ryd kompilationsmappen op * **clsi**: skriv alle dokumenter i kompilationsmappen * **clsi**: skriv alle binære filer i kompilationsmappen * `clsi` kopierer filerne fra en lokal cache pr. projekt * ved cache-miss: * **clsi** -> **filestore**: download filer * **clsi**: skriv "projekttilstanden" * **clsi**: sørg for, at der findes en Docker-container med den ønskede konfiguration * opbyg containerindstillinger, inklusive TeX Live-version * hash-indstillinger * containernavn: `project---` * **clsi**: start containeren og stream stdout/stderr til hukommelsen -> grænse 2 MB * **clsi**: efterlad den stoppede container -> ryddes op efter 24 timer * **clsi**: skriv stdout/stderr til disk * **clsi**: kopier outputfiler til unik outputmappe * build-id sammensat af 8 tilfældige bytes plus tidsstempel med ms-præcision * slet alle undtagen de sidste 3 (anonyme) / den sidste 1 (loggede ind bruger) build-mapper * **clsi**: kompileringen mislykkedes/timede ud * slet kompilationscache — den kan indeholde delvise filer/korrupte cachedata * **editor**: downloader output.log og output.pdf **Kompilering — "inkrementel" synkroniseringstilstand** * **editor**: sender kompilationsanmodning med synkroniseringstilstand sat til "inkrementel" * **web** -> **document-updater**: hent eventuelle dokumenter fra Redis * "projekttilstanden"-hashen gemmes også i Redis * **web** sender hash-hvælvet af filtræet til `document-updater` og `document-updater` kan omdanne den inkrementelle kompilering til en fuld kompilering ved uoverensstemmelse * se kompilationsprocessen, som den udføres, når editoren anmodede om en "fuld" kompilering * **web** -> **clsi**: kompilationsanmodning sendes til `clsi`, inklusive: * synkroniseringstilstanden * en hash af filtræet -> "projekttilstanden" * alle dokumenter fra Redis med deres indhold -> underlagt en grænse på 7 MB for anmodningens brødtekst * ingen binære filer * **clsi**: tjek disktilstanden med synkroniseringstilstanden og "projekttilstanden" * dette er en inkrementel synkronisering, så "projekttilstanden" skal matche * ved uoverensstemmelse: svar med 409, og lad web prøve igen med "fuld" synkronisering * se kompilationsprocessen, som den udføres, når editoren anmodede om en "fuld" kompilering * **clsi**: skriv opdaterede dokumenter i kompilationsmappen * **clsi**: sørg for, at der findes en Docker-container med den ønskede konfiguration * opbyg containerindstillinger, inklusive TeX Live-version * hash-indstillinger * containernavn: `project---` * **clsi**: start containeren og stream stdout/stderr til hukommelsen -> grænse 2 MB * **clsi**: efterlad den stoppede container -> ryddes op efter 24 timer * **clsi**: skriv stdout/stderr til disk * **clsi**: kopier outputfiler til unik outputmappe * build-id sammensat af 8 tilfældige bytes plus tidsstempel med ms-præcision * slet alle undtagen de sidste 3 (anonyme) / den sidste 1 (loggede ind bruger) build-mapper * **clsi**: kompileringen mislykkedes/timede ud * slet kompilationscache — den kan indeholde delvise filer/korrupte cachedata * **editor**: downloader output.log og output.pdf **Kompilering — skift mellem tilstande** * **editor**: registrerer en kompileringsfejl, næste kompilering er en "fuld" kompilering * **editor**: registrerer en vellykket kompilering, næste kompilering er en "inkrementel" 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/da/kom-godt-i-gang/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.