> 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/on-premises-no/kom-i-gang/microservices.md). # Mikrotjenester Den anbefalte måten å distribuere og administrere Overleaf Server CE- og Overleaf Pro-instanser på er å bruke Toolkit. Toolkit forenkler opprettelsen av din Overleaf-instans ved å bruke noen egendefinerte skript som abstraherer bort orkestreringen av nødvendige mikrotjenester. Kjør ganske enkelt det medfølgende initialiseringsskriptet, oppgi noen få konfigurasjonsvalg som banene til vedvarende lagring, og Toolkit vil sørge for klargjøring og tilkobling av mikrotjenestene som utgjør din Overleaf Server CE- eller Pro-instans. Dette lar deg fokusere på å tilpasse brukeropplevelsen og implementere de spesifikke funksjonene som utgjør din lokale instans. Toolkit håndterer all kompleksiteten bak kulissene, og muliggjør en forenklet utrulling av din Overleaf-instans. {% hint style="info" %} Av historiske grunner kalles hovedcontaineren for Overleaf `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 mer detaljer. På et tidspunkt i fremtiden vil dette bli omdøpt slik at det samsvarer med Overleaf-navneskjemaet. {% endhint %} #### Arkitektur Inne i Overleaf-containeren kjører programvaren som et sett med mikrotjenester, styrt av `runit`. Noen av de mer interessante filene inne i 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 (samsvarer med katalogen angitt av `OVERLEAF_DATA_PATH` på verten). #### 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, til sammen 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://overleaf-pro.ayaka.space/on-premises/on-premises-no/kom-i-gang/pages/7b082d30e8a86326a834f238a7fe63c31c5657de#the-overleaf.rc-file) konfigurasjonsfilen. {% endhint %} #### Editor 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, som bare er tilgjengelig i Overleaf Pro. I Server CE bruker kompileringsprosessen enkle underprosesser — erstatt elementene som refererer til en **containeren** 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 websocket-er * `web` — Den (ikke så) mikrotjenesten som brukes til å håndtere API-forespørsler **Redis-cache** * **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 det har gått 5 minutter siden siste tømming (per dokument): * **document-updater**: tøm dokumentet 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 inn i 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-modus * en hash av filtreet -> «prosjektstatusen» * alle dokumenter med innhold -> underlagt grensen på 7 MB for forespørselsbrødtekst * URL-er til binærfiler for separat nedlasting * **clsi**: sjekk tilstand på disk med synk-modus og «prosjektstatus» * dette er en full synk, så tidligere tilstand på disk kan ignoreres * **clsi**: rydd kompilermappe * **clsi**: skriv alle dokumenter inn i kompilermappen * **clsi**: skriv alle binærfiler inn i kompilermappen * `clsi` kopierer filene fra en lokal hurtigbuffer per prosjekt * ved cache-miss: * **clsi** -> **filestore**: last ned filer * **clsi**: skriv «prosjektstatusen» * **clsi**: sørg for at Docker-containeren finnes med ønsket konfigurasjon * bygg containeralternativer, inkluderer TeX Live-versjon * hash-alternativer * containernavn: `project---` * **clsi**: start containeren og strømm stdout/stderr inn i minnet -> grense 2 MB * **clsi**: la den stoppede containeren bli liggende -> ryddes opp etter 24 timer * **clsi**: skriv stdout/stderr til disk * **clsi**: kopier utdatafilene til en unik utdatakatalog * build-id sammensatt av 8 tilfeldige byte pluss tidsstempel med millisekundpresisjon * slett alle unntatt de siste 3 (anonyme) / siste 1 (innlogget bruker) byggemappene * **clsi**: kompileringen mislyktes/timet ut * slett kompileringsbufferen — den kan ha delvise filer/skadet buffer * **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 * «prosjektstatus»-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-modus * en hash av filtreet -> «prosjektstatusen» * alle dokumenter fra Redis med innholdet sitt -> underlagt grensen på 7 MB for forespørselsbrødtekst * ingen binærfiler * **clsi**: sjekk tilstand på disk med synk-modus og «prosjektstatus» * dette er en inkrementell synk, så «prosjektstatusen» må stemme overens * 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 kompilermappen * **clsi**: sørg for at Docker-containeren finnes med ønsket konfigurasjon * bygg containeralternativer, inkluderer TeX Live-versjon * hash-alternativer * containernavn: `project---` * **clsi**: start containeren og strømm stdout/stderr inn i minnet -> grense 2 MB * **clsi**: la den stoppede containeren bli liggende -> ryddes opp etter 24 timer * **clsi**: skriv stdout/stderr til disk * **clsi**: kopier utdatafilene til en unik utdatakatalog * build-id sammensatt av 8 tilfeldige byte pluss tidsstempel med millisekundpresisjon * slett alle unntatt de siste 3 (anonyme) / siste 1 (innlogget bruker) byggemappene * **clsi**: kompileringen mislyktes/timet ut * slett kompileringsbufferen — den kan ha delvise filer/skadet buffer * **editor**: laster ned output.log og output.pdf **Kompilering — bytte mellom moduser** * **editor**: observerer en kompileringsfeil, neste kompilering er en «full» kompilering * **editor**: observerer en 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://overleaf-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.