> 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/da/kom-godt-i-gang/microservices.md). # Mikrotjenester Den anbefalede måde at implementere og administrere Overleaf Server CE- og Overleaf Pro-instanser på er at bruge Toolkit. Toolkit forenkler oprettelsen af din Overleaf-instans ved hjælp af nogle brugerdefinerede scripts, der abstraherer orkestreringen af de nødvendige mikrotjenester. Kør blot det medfølgende initialiseringsscript, angiv et par konfigurationsindstillinger som dine stier til vedvarende lager, og Toolkit tager sig af at provisionere og forbinde de mikrotjenester, der udgør din Overleaf Server CE- eller Pro-instans. Det giver dig frihed til at 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 udrulning af din Overleaf-instans. {% hint style="info" %} Af hensyn til bagudkompatibilitet kaldes den primære Overleaf-container `sharelatex`, og er baseret på `sharelatex/sharelatex` Docker-afbildningen. Dette 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 navngivningsskema. {% endhint %} #### Arkitektur Inde i Overleaf-containeren kører softwaren som et sæt mikrotjenester, administreret 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/`: monteringspunktet for vedvarende data (svarer til den mappe, der er angivet af `OVERLEAF_DATA_PATH` på værten). #### MongoDB- og Redis-containere Overleaf er afhængig af to eksterne databaser: MongoDB og Redis. Som standard vil Toolkit provisionere en container til hver af disse databaser, ud over Overleaf-containeren, i alt 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://ayakaleaf-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 elementerne, der henviser til en **container** 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 bruges til at håndtere web-sockets * `web` — Den (ikke så) mikrotjeneste, der bruges til at håndtere API-anmodninger **Redis-cache** * **bruger**: indlæser editorsiden * **editor**: åbner web-socket * **editor**: sender anmodning om at åbne et dokument via web-socket * **real-time** -> **document-updater**: dokumentet indlæses fra MongoDB til Redis * **editor**: sender dokumentopdatering via web-socket * **real-time** -> **document-updater**: dokumentet opdateres i Redis * **editor**: sender flere kompileringsanmodninger * Efter 5 minutter er gået siden sidste flush (pr. dokument): * **document-updater**: tøm dokumentet fra Redis til MongoDB * **editor**: sender flere opdateringer * for hver 100 opdateringer (pr. dokument): * **document-updater**: tøm dokumenthistorik fra Redis til MongoDB * **bruger**: forlader editoren/lukker browserfanen * 5 minutter senere * **real-time**: tjekker for andre samarbejdspartnere, hvis der ikke er nogen: * **real-time** -> **document-updater**: tømmer dokumenter fra Redis til MongoDB **Læsning fra MongoDB til Redis** * **document-updater** -> **web** -> **docstore**: læs fra MongoDB **Tømning fra Redis til MongoDB** * **document-updater** -> **web** -> **docstore**: skriv til MongoDB **Kompilering — "fuld" synkroniseringstilstand** * **editor**: sender kompileringsanmodning med sync-mode sat til "fuld" * **web** -> **document-updater**: eventuelle dokumenter tømmes fra Redis til MongoDB * **web** -> **docstore**: alle dokumenter downloades fra MongoDB * **web** -> **clsi**: kompileringsanmodning sendes til `clsi`, inklusive: * sync-tilstanden * et hash af filtæet -> "projekttilstanden" * alle dokumenter med deres indhold -> underlagt 7 MB grænse for anmodningens brødtekst * URL'er til binære filer til separat download * **clsi**: tjek af tilstand på disken med sync-tilstand og "projekttilstand" * dette er en fuld synkronisering, så den tidligere tilstand på disken kan ignoreres * **clsi**: ryd compile-mappen * **clsi**: skriv alle dokumenter til compile-mappen * **clsi**: skriv alle binære filer til compile-mappen * `clsi` kopierer filerne fra en lokal cache pr. projekt * ved cache-miss: * **clsi** -> **filestore**: download filer * **clsi**: skriv "projekttilstanden" * **clsi**: sørg for, at Docker-containeren findes med den ønskede konfiguration * opbyg containerindstillinger, inkluderer texlive-version * hash-indstillinger * containernavn: `projekt---` * **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 outputfilerne til en unik outputmappe * build-id sammensat af 8 tilfældige bytes plus tidsstempel med ms-præcision * slet alle undtagen de sidste 3 (anonyme) / sidste 1 (loggede ind bruger) build-mapper * **clsi**: kompileringsfejl/timeout * slet kompilercachen — den kan have delvise filer/beskadiget cache * **editor**: downloader output.log og output.pdf **Kompilering — "inkrementel" synkroniseringstilstand** * **editor**: sender kompileringsanmodning med sync-mode sat til "inkrementel" * **web** -> **document-updater**: hent eventuelle dokumenter fra Redis * "projekttilstanden"-hashen er også gemt i Redis * **web** sender hash'en af filtæet til `document-updater` og `document-updater` kan gøre den inkrementelle kompilering til en fuld kompilering ved uoverensstemmelse * se kompileringsprocessen, som udføres når editoren anmodede om "fuld" kompilering * **web** -> **clsi**: kompileringsanmodning sendes til `clsi`, inklusive: * sync-tilstanden * et hash af filtæet -> "projekttilstanden" * alle dokumenter fra Redis med deres indhold -> underlagt 7 MB grænse for anmodningens brødtekst * ingen binære filer * **clsi**: tjek af tilstand på disken med sync-tilstand og "projekttilstand" * dette er en inkrementel synkronisering, så "projekttilstanden" skal stemme overens * ved uoverensstemmelse: svar med 409, lad web prøve igen med "fuld" synkronisering * se kompileringsprocessen, som udføres når editoren anmodede om "fuld" kompilering * **clsi**: skriv opdaterede dokumenter til compile-mappen * **clsi**: sørg for, at Docker-containeren findes med den ønskede konfiguration * opbyg containerindstillinger, inkluderer texlive-version * hash-indstillinger * containernavn: `projekt---` * **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 outputfilerne til en unik outputmappe * build-id sammensat af 8 tilfældige bytes plus tidsstempel med ms-præcision * slet alle undtagen de sidste 3 (anonyme) / sidste 1 (loggede ind bruger) build-mapper * **clsi**: kompileringsfejl/timeout * slet kompilercachen — den kan have delvise filer/beskadiget cache * **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://ayakaleaf-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.