> 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/on-premises-no/kom-i-gang/microservices.md). # Mikrotjenester Den anbefalte måten å distribuere og administrere Overleaf Server CE- og Overleaf Pro-instansene på er å bruke Toolkit. Toolkit forenkler opprettelsen av Overleaf-instansen din ved hjelp av noen egendefinerte skript som abstraherer bort orkestreringen av nødvendige mikrotjenester. Kjør bare det medfølgende initialiseringsskriptet, oppgi noen få konfigurasjonsalternativer som stiene til vedvarende lagring, og Toolkit tar seg av å klargjøre og koble til mikrotjenestene som utgjør Overleaf Server CE- eller Pro-instansen din. Dette gir deg frihet til å fokusere på å tilpasse brukeropplevelsen og implementere de spesifikke funksjonene som utgjør din lokale instans. Toolkit håndterer all kompleksiteten i bakgrunnen, noe som muliggjør en forenklet utrulling av Overleaf-instansen din. {% hint style="info" %} Av historiske årsaker kalles hoved-Overleaf-containeren `sharelatex`og er basert på `sharelatex/sharelatex` Docker-avbildningen. Dette er fordi teknologien er basert på ShareLaTeX-kodebasen, som ble slått sammen med Overleaf. Se [denne bloggpostenarrow-up-right](https://www.overleaf.com/blog/518-exciting-news-sharelatex-is-joining-overleaf) for flere detaljer. På et tidspunkt i fremtiden vil dette bli gitt nytt navn for å samsvare med Overleafs navnekonvensjon. {% endhint %} #### Arkitektur Inni Overleaf-containeren kjører programvaren som et sett mikrotjenester, administrert av `runit`. Noen av de mer interessante filene inni containeren er: * `/etc/service/`: initialiseringsfiler for mikrotjenestene. * `/var/log/overleaf/`: logger for hver mikrotjeneste. * `/overleaf/services/`: kode for de ulike mikrotjenestene. * `/var/lib/overleaf/`: monteringspunktet for vedvarende data (tilsvarer katalogen angitt av `OVERLEAF_DATA_PATH` på vertsmaskinen). #### MongoDB- og Redis-containerne Overleaf er avhengig av to eksterne databaser: MongoDB og Redis. Som standard vil Toolkit klargjøre en container for hver av disse databasene, i tillegg til Overleaf-containeren, slik at det totalt blir tre Docker-containere. {% hint style="info" %} Hvis du heller vil koble til en eksisterende MongoDB- eller Redis-instans, kan du gjøre det ved å angi de relevante innstillingene i [overleaf.rc](https://ayakaleaf-pro.ayaka.space/on-premises/on-premises-no/kom-i-gang/pages/7b082d30e8a86326a834f238a7fe63c31c5657de#the-overleaf.rc-file) konfigurasjonsfilen. {% endhint %} #### Redigerings- og kompileringsprosess Denne delen gir en overordnet oversikt over håndteringen av dokumenter og kompileringsprosessen. {% hint style="info" %} Denne siden beskriver kompileringsprosessen med Sandboxed Compiles, slik den bare er tilgjengelig i Overleaf Pro. I Server CE bruker kompileringsprosessen enkle underprosesser — erstatt elementene som refererer til en **beholderen** med ett enkelt element **kjør kompilering i underprosess**. {% endhint %} Komponenter / aktører: * `bruker` — En bruker av applikasjonen * `editor` — Klientapplikasjonen som kjører i nettleseren * `clsi` — Mikrotjenesten som brukes til å kompilere PDF-er * `document-updater` — Mikrotjenesten som brukes til å behandle dokumentoppdateringer * `filestore` — Mikrotjenesten som håndterer binærfiler * `real-time` — Mikrotjenesten som brukes til å håndtere websockets * `web` — Den (ikke fullt så) mikrotjenesten som brukes til å håndtere API-forespørsler **Redis-hurtigbufring** * **bruker**: laster redigeringssiden * **editor**: åpner websocket * **editor**: sender forespørsel om å åpne et dokument via websocket * **real-time** -> **document-updater**: dokumentet lastes fra MongoDB inn i Redis * **editor**: sender dokumentoppdatering via websocket * **real-time** -> **document-updater**: dokumentet oppdateres i Redis * **editor**: sender flere kompileringsforespørsler * Etter at 5 minutter har gått siden siste tømming (per dokument): * **document-updater**: tøm dokument fra Redis til MongoDB * **editor**: sender flere oppdateringer * hver 100. oppdatering (per dokument): * **document-updater**: tøm dokumenthistorikk fra Redis til MongoDB * **bruker**: forlater editoren/lukker nettleserfanen * 5 minutter senere * **real-time**: sjekker om det finnes andre samarbeidspartnere, hvis det ikke er noen: * **real-time** -> **document-updater**: tømmer dokumenter fra Redis til MongoDB **Lesing fra MongoDB inn i Redis** * **document-updater** -> **web** -> **docstore**: les fra MongoDB **Tømming fra Redis til MongoDB** * **document-updater** -> **web** -> **docstore**: skriv til MongoDB **Kompilering — «full» synk-modus** * **editor**: sender kompileringsforespørsel med synk-modus satt til «full» * **web** -> **document-updater**: eventuelle dokumenter tømmes fra Redis til MongoDB * **web** -> **docstore**: alle dokumenter lastes ned fra MongoDB * **web** -> **clsi**: kompileringsforespørselen sendes til `clsi`, inkludert: * synk-modusen * en hash av filtreet -> «prosjektstatusen» * alle dokumenter med innholdet sitt -> begrenset av en forespørselskropp på 7 MB * nettadresser til binærfiler for separat nedlasting * **clsi**: sjekk tilstanden på disk mot synk-modusen og «prosjektstatusen» * dette er en full synk, så tidligere tilstand på disk kan ignoreres * **clsi**: rydd opp i kompileringskatalogen * **clsi**: skriv alle dokumenter inn i kompileringskatalogen * **clsi**: skriv alle binærfiler inn i kompileringskatalogen * `clsi` kopierer filene fra en lokal hurtigbuffer per prosjekt * ved bom i hurtigbufferen: * **clsi** -> **filestore**: last ned filer * **clsi**: skriv «prosjektstatusen» * **clsi**: sørg for at Docker-containeren finnes med ønsket konfigurasjon * bygg containeralternativer, inkludert TeX Live-versjon * hash-alternativer * containernavn: `project---` * **clsi**: start containeren og strøm stdout/stderr inn i minnet -> grense 2 MB * **clsi**: la den stoppede containeren bli igjen -> ryddes opp etter 24 t * **clsi**: skriv stdout/stderr til disk * **clsi**: kopier utdatafiler til en unik utdatakatalog * build-id sammensatt av 8 tilfeldige byte pluss tidsstempel med ms-presisjon * slett alle bortsett fra de siste 3 (anonyme) / siste 1 (innloggede bruker) byggemappene * **clsi**: kompileringen mislyktes/timet ut * slett kompileringshurtigbufferen — den kan ha delvise filer/ødelagt hurtigbuffer * **editor**: laster ned output.log og output.pdf **Kompilering — «inkrementell» synk-modus** * **editor**: sender kompileringsforespørsel med synk-modus satt til «inkrementell» * **web** -> **document-updater**: hent eventuelle dokumenter fra Redis * «prosjektstatusen»-hasjen lagres også i Redis * **web** sender hashen av filtreet til `document-updater` og `document-updater` kan gjøre den inkrementelle kompileringen om til en full kompilering ved avvik * se kompileringsprosessen slik den utføres når editoren ba om «full» kompilering * **web** -> **clsi**: kompileringsforespørselen sendes til `clsi`, inkludert: * synk-modusen * en hash av filtreet -> «prosjektstatusen» * alle dokumenter fra Redis med innholdet sitt -> begrenset av en forespørselskropp på 7 MB * ingen binærfiler * **clsi**: sjekk tilstanden på disk mot synk-modusen og «prosjektstatusen» * dette er en inkrementell synk, så «prosjektstatusen» må stemme * ved avvik: svar med 409, la web prøve på nytt med «full» synk * se kompileringsprosessen slik den utføres når editoren ba om «full» kompilering * **clsi**: skriv oppdaterte dokumenter inn i kompileringskatalogen * **clsi**: sørg for at Docker-containeren finnes med ønsket konfigurasjon * bygg containeralternativer, inkludert TeX Live-versjon * hash-alternativer * containernavn: `project---` * **clsi**: start containeren og strøm stdout/stderr inn i minnet -> grense 2 MB * **clsi**: la den stoppede containeren bli igjen -> ryddes opp etter 24 t * **clsi**: skriv stdout/stderr til disk * **clsi**: kopier utdatafiler til en unik utdatakatalog * build-id sammensatt av 8 tilfeldige byte pluss tidsstempel med ms-presisjon * slett alle bortsett fra de siste 3 (anonyme) / siste 1 (innloggede bruker) byggemappene * **clsi**: kompileringen mislyktes/timet ut * slett kompileringshurtigbufferen — den kan ha delvise filer/ødelagt hurtigbuffer * **editor**: laster ned output.log og output.pdf **Kompilering — bytte mellom moduser** * **editor**: observerer en kompileringsfeil, neste kompilering er en «full» kompilering * **editor**: observerer vellykket kompilering, neste kompilering er 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/on-premises-no/kom-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.