Slik drifter du Gotenberg selv i 2026: HTML til PDF, tidsavbrudd og skrifter

En mislykket Gotenberg-distribusjon krasjer ikke alltid. Den kan vise en innloggingsside mens forespørsler bruker feil multipart-felt, eller konverteringer kan overskride proxy-tidsavbrudd. Start heller med en ende-til-ende-kontroll: send HTML og ressurser som multipart-data, gjengi en PDF, gjenta med et Office-dokument og kontroller health-endepunktet etter hver konvertering.

Denne kontrollen samsvarer med det dokumenterte formålet til Gotenberg: en HTTP-tjeneste som konverterer HTML-, Markdown- og Office-filer til PDF. Den avdekker også manglende avhengigheter, feil antakelser om proxyen og flyktige data tidligere enn en enkel oppetidssjekk kan.

Porter, prosesser og private tjenester

Ikke la Gotenberg-imaget velge produksjonsarkitekturen ved et uhell. Imaget leverer en prosess på port 3000, men lagring, ruting og eksterne krav trenger fortsatt bevisste livssykluser. Det lokale runtime-kravet er tilstrekkelig CPU- og minnekapasitet for Chromium- og LibreOffice-workerne. Test denne grensen før eksponering og på nytt etter at en container er byttet ut.

Distribusjonen er klar for mer omfattende testing når den kan sende HTML og ressurser som multipart-data, gjengi en PDF, gjenta med et Office-dokument og kontrollere health-endepunktet etter hver konvertering. Følg transaksjonen i loggene og overvåk antall Chromium- og LibreOffice-prosesser, midlertidig disk, dokumentkompleksitet og proxy-tidsavbrudd. Disse observasjonene viser om den nåværende topologien isolerer riktig komponent.

Gjør Gotenberg-gjenoppretting målbar

Det forventes ingen skrivbar applikasjonstilstand i standardimaget for Gotenberg. Ikke bevar varige applikasjonsdata; ta vare på skrifter, maler og distribusjonskonfigurasjon, inkludert den låste digesten og den gjennomgåtte rutekonfigurasjonen, i stedet for å sikkerhetskopiere et tomt containerfilsystem.

Opprett Gotenberg fra bunnen av på en annen vert, og bekreft at egendefinerte skrifter, maler og kommandoflagg kan gjenskapes, samt at kjente dokumenter gjengis med forventet sidetall. Hvis en separat database, romserver eller autentiseringslag legges til, skal denne komponenten ha sin egen tydelige eier for gjenoppretting. Veiledningen fra Git til produksjon viser hvordan et reproduserbart artifact erstatter en containersikkerhetskopi.

Dokumenter gjenoppbyggingskommandoen og testen med kjent resultat sammen med releasen. En tilstandsløs gjenopprettingsplan lykkes ved å gjenskape atferd fra pålitelige inndata; den bør ikke være avhengig av å kopiere en ugjennomsiktig container som kjører.

Begrens hvilke rettigheter Gotenberg har

Den verdifulle ressursen i Gotenberg er koden som håndterer brukerinndata. Den applikasjonsspesifikke risikoen er å tillate ubegrensede offentlige konverteringer uten størrelses- og tidsavbruddskontroller. I produksjon bør konverteringsendepunktene være private, eller størrelses-, rate- og tidsavbruddskontroller håndheves før upålitelige filer tillates.

Standardcontaineren har ingen administratorhemmelighet, så autentisering hører hjemme på HTTPS-ruten hvis tjenesten er privat. Lås bygget, unngå brede filsystemmonteringer og begrens antall Chromium- og LibreOffice-prosesser, midlertidig disk, dokumentkompleksitet og proxy-tidsavbrudd. Bruk kjente testdata for å bekrefte at bygget som leveres, produserer forventet resultat etter hver oppdatering.

Gotenberg-sjekkpunktet før release

Gjør Gotenberg-smoketesten om til en repeterbar release-kommando eller en kort runbook. Resultatet må demonstrere dette: send HTML og ressurser som multipart-data, gjengi en PDF, gjenta med et Office-dokument og kontroller health-endepunktet etter hver konvertering. Registrer applikasjonsversjon, container-digest, vertsnavn for ruten og identifikator for testdataene sammen med resultatet.

Kjør den samme kontrollen etter et rutinemessig containerbytte og etter gjenoppretting uten varige applikasjonsdata. Bevar skrifter, maler og distribusjonskonfigurasjon et annet sted. Gjenopprettingen er vellykket når egendefinerte skrifter, maler og kommandoflagg kan gjenskapes, og kjente dokumenter gjengis med forventet sidetall. Sammenlign tidsbruk og ressursforbruk knyttet til antall Chromium- og LibreOffice-prosesser, midlertidig disk, dokumentkompleksitet og proxy-tidsavbrudd. En stor endring bør undersøkes selv når den endelige handlingen fortsatt består.

Test deretter en trygg feil: send inn ufarlige data nær ressurs- eller formatgrensen som gjelder for denne grensen: forespørsler bruker feil multipart-felt, eller konverteringer overskrider proxy-tidsavbrudd. Bekreft at Gotenberg viser feilen og går tilbake til normal drift uten destruktive manuelle endringer. Ta vare på bare det nødvendige, redigerte utdraget fra loggen. Dette firedelte sjekkpunktet dekker oppstart, persistens, gjenoppretting og feilhåndtering.

Gjør Gotenberg-oppstarten reproduserbar

Bruk en kommando som synliggjør alle viktige valg. Denne grunnkonfigurasjonen binder Gotenberg til loopback på verten, legger til de kjente datamonteringene og angir den første nødvendige innstillingen. Bekreft det lokale kravet før eksponering: tilstrekkelig CPU- og minnekapasitet for Chromium- og LibreOffice-workerne.

docker run -d \
  --name gotenberg \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  gotenberg/gotenberg:8

Bytt ut flytende tagger med en testet versjon eller digest. Etter oppstart kontrollerer du docker logs --tail 200 gotenberg og bekrefter at prosessen lytter på port 3000. Kjør deretter Gotenberg-akseptansetesten. Et svar fra rotsiden kan ikke bevise at hele scenarioet fungerer: send HTML og ressurser som multipart-data, gjengi en PDF, gjenta med et Office-dokument og kontroller health-endepunktet etter hver konvertering.

Unngå at en vellykket proxy skjuler applikasjonsfeil

Velg det endelige Gotenberg-vertsnavnet før brukere lagrer callbacker eller klientinnstillinger, og eksponer deretter konverterings-API-et via HTTPS eller et privat internt domene. Plattformruten bør terminere TLS én gang og målrette den private porten 3000.

Kjør akseptansetransaksjonen eksternt. Hvis klienten aldri når Gotenberg, bruker du sjekklisten for SSL-validering for DNS- og sertifikatkontroller. Hvis forespørselen når Gotenberg, men forespørsler bruker feil multipart-felt eller konverteringer overskrider proxy-tidsavbrudd, må du slutte å endre proxy-redirecter og undersøke den applikasjonsspesifikke grensen i stedet.

Kapasitets- og oppgraderingskontroller

Det nyttige tjenesteindikatoren for Gotenberg er at følgende fullføres: «send HTML og ressurser som multipart-data, gjengi en PDF, gjenta med et Office-dokument og kontroller health-endepunktet etter hver konvertering». Kombiner dette resultatet med antall Chromium- og LibreOffice-prosesser, midlertidig disk, dokumentkompleksitet og proxy-tidsavbrudd. En grønn rotside sier ingenting om utdataenes kompatibilitet eller ressursmangel.

Før du bytter imaget, må du ta høyde for denne risikoen: API-ruter, Chromium-flagg og LibreOffice-atferd kan endres mellom større Gotenberg-versjoner. Test representative inndata og grenseverdier mot begge versjonene, og behold den gamle digesten til kandidaten består. Hvis forespørsler bruker feil multipart-felt eller konverteringer overskrider proxy-tidsavbrudd, må du undersøke forespørselsformatet, klientatferden og runtime-loggene før du endrer rute- eller lagringsinnstillinger.

Slik reduserer Dockup arbeidet med Gotenberg

En Gotenberg-mal med ett klikk bør angi image-digest, port 3000, health-timing, domene og TLS. Siden basistjenesten er tilstandsløs, kan Dockup opprette den direkte på Dockup compute eller en tilkoblet maskin uten å late som om et tomt volum er en sikkerhetskopi.

Etter oppstart eksponerer du konverterings-API-et via HTTPS eller et privat internt domene. Dockup bør bevare runtime-innstillingene for Gotenberg mens operatøren bekrefter dette lokale kravet: tilstrekkelig CPU- og minnekapasitet for Chromium- og LibreOffice-workerne. Bekreft dette resultatet: send HTML og ressurser som multipart-data, gjengi en PDF, gjenta med et Office-dokument og kontroller health-endepunktet etter hver konvertering. Eventuelle senere tilstandsfulle utvidelser må angi sin egen montering, hemmelighet og gjenopprettingstest, i stedet for å endre betydningen av basemalen i det skjulte.

Ofte stilte spørsmål

Hva trenger Gotenberg for en produksjonsdistribusjon?

Rout Gotenberg-containeren på port 3000 gjennom én HTTPS-opprinnelse. Det lokale runtime-kravet er tilstrekkelig CPU- og minnekapasitet for Chromium- og LibreOffice-workerne. Ikke erklær Gotenberg klar før du kan sende HTML og ressurser som multipart-data, gjengi en PDF, gjenta med et Office-dokument og kontrollere health-endepunktet etter hver konvertering.

Hvilke Gotenberg-data hører hjemme i en sikkerhetskopi?

Standardimaget for Gotenberg har ingen obligatorisk montering for applikasjonsdata. Bevar distribusjonskonfigurasjonen og sikkerhetskopier tilkoblet tilstand separat. Gjenopprettingen er godkjent når egendefinerte skrifter, maler og kommandoflagg kan gjenskapes, og kjente dokumenter gjengis med forventet sidetall.

Krever Gotenberg HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Gotenberg-opprinnelsen og behold port 3000 på den interne ruten. Bruk Gotenberg-innstillingen riktig: eksponer konverterings-API-et via HTTPS eller et privat internt domene. For Gotenberg beskytter HTTPS legitimasjon eller brukerinnhold under overføring og sørger for konsistent klientatferd som er avhengig av opprinnelsen.

Hvordan bør en Gotenberg-oppgradering testes?

Distribuer kandidat-imaget for Gotenberg ved siden av det nåværende, og gjenta akseptansetransaksjonen med kjente inndata. Vær spesielt oppmerksom på at API-ruter, Chromium-flagg og LibreOffice-atferd kan endres mellom større Gotenberg-versjoner. Standardcontaineren har ingen datamigrering, så behold den forrige digesten til kontroller av utdata og kompatibilitet er bestått.