Slik selvhoster du Wiki.js i 2026: databaseoppsett, TLS og gjenopprettingstester

De fleste installasjonsnotater for Wiki.js stopper etter den første sideinnlastingen. Det er for tidlig: DB_HOST er localhost inne i containeren, eller TLS-proxyheaderne mangler. En nyttig produksjonstest er mer krevende — fullfør oppsettet, opprett og rediger en side, last opp medier, søk etter siden og kontroller versjonshistorikken etter en omstart.

Wiki.js har en tydelig rolle: en Markdown-wiki med versjonering og en moderne editor. Driftsgrensene omfatter mer enn webprosessen, så avhengighetene, den lagrede tilstanden og den offentlige ruten må navngis eksplisitt før ekte data tas i bruk.

Tegn opp kjøretidsgrensen for Wiki.js

Den minste ansvarlige topologien for Wiki.js består av én privat lytter på port 3000, en ingressrute og en dokumentert tilstandsgrense. Nettverkskontrakten for Wiki.js er en tilgjengelig Postgres-, MySQL-, MariaDB-, MSSQL- eller SQLite-database. Hold private endepunkter på intern DNS, tillat bare nødvendige utgående kall og gi Wiki.js en tjenestekonto med begrenset tilgang.

Valider topologien ved å be en ren klient fullføre oppsettet, opprette og redigere en side, laste opp medier, søke etter siden og kontrollere versjonshistorikken etter en omstart. Følg med på svartid for databasen, søkeindeksering, medielagring og forsinkelse hos autentiseringsleverandøren mens testen kjører. Resultatet forteller deg om den neste forbedringen hører hjemme i minne, lagring, nettverk eller en separat worker, i stedet for å oppmuntre til vilkårlig dimensjonering av containeren.

Utform gjenopprettingen av Wiki.js før lansering

Det forventes ingen skrivbar applikasjonstilstand i standardimaget for Wiki.js. Bevar databasen samt eventuelle lokale opplastinger og egendefinerte ressurser, inkludert den låste digest-en og den gjennomgåtte rutekonfigurasjonen, i stedet for å sikkerhetskopiere et tomt containerfilsystem.

Opprett Wiki.js fra grunnen av på en annen vert og kontroller at sider, historikk, brukere, grupper, medier og navigasjon kommer tilbake, og at en kjent side fortsatt kan søkes opp. Hvis du legger til en separat database, room server eller et autentiseringslag, må komponenten få sin egen, eksplisitte gjenopprettingsansvarlige. Veiledningen fra Git til produksjon viser hvordan et reproduserbart artifact erstatter en containersikkerhetskopi.

Registrer gjenoppbyggingskommandoen og testen med kjent utdata 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 i drift.

Velg tillitsgrensen for Wiki.js

En sikker Wiki.js-distribusjon starter med å fjerne privilegier. Unngå å la oppsettsiden være offentlig tilgjengelig etter at den første administratoren er opprettet. Fjern i stedet offentlig tilgang til oppsettet, begrens administrasjonen og gi wiki-databasen egne innloggingsopplysninger.

Behandle DB_PASS i tråd med rollen variabelen har i Wiki.js: hold sensitive verdier utenfor Git, dokumenter konsekvensene av rotasjon og bruk aldri et offentlig eksempel i produksjon. Begrens administrative ruter, bruk privat DNS for avhengigheter og gå gjennom hver bind mount. Når logger sendes til en sentral løsning, må du filtrere bort hemmeligheter og privat innhold før de forlater serveren.

Dette må bestås før ekte Wiki.js-data tas i bruk

En produksjonskontroll for Wiki.js bør kunne utføres av noen som ikke bygget distribusjonen. Gi personen den låste versjonen, en ikke-sensitiv testkonto og denne oppgaven: fullfør oppsettet, opprett og rediger en side, last opp medier, søk etter siden og kontroller versjonshistorikken etter en omstart. Hvis instruksjonene krever udokumentert shell-tilgang, er tjenesten ennå ikke driftsklar.

Gjenta kontrollen etter å ha byttet ut bare containeren. Gjenopprett deretter databasen samt eventuelle lokale opplastinger og egendefinerte ressurser til tom infrastruktur, og bevis at sider, historikk, brukere, grupper, medier og navigasjon kommer tilbake, og at en kjent side fortsatt kan søkes opp. Mål svartid for databasen, søkeindeksering, medielagring og forsinkelse hos autentiseringsleverandøren under begge vellykkede kjøringer. Uventede forskjeller avdekker ofte en manglende cache, indeks, worker eller datamontasje.

Legg til en feilsituasjonsøvelse: nekt testidentiteten midlertidig tilgang til en tilgjengelig Postgres-, MySQL-, MariaDB-, MSSQL- eller SQLite-database. Wiki.js skal logge en nyttig feil, bevare eksisterende tilstand og gjenopprettes når den gyldige betingelsen kommer tilbake. Lagre tidsstemplene og relevante logglinjer, med hemmeligheter maskert. Disse bevisene blir referansen for neste image- eller konfigurasjonsendring.

Start Wiki.js uten å skjule de bevegelige delene

Hold den første påkallingen av Wiki.js så reproduserbar at den kan gjennomgås i en pull request.

docker run -d \
  --name wiki-js \
  --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -e DB_PASS=replace-with-a-long-random-value \
  -e DB_TYPE=postgres \
  -e DB_HOST=postgres.internal \
  -e DB_PORT=5432 \
  -e DB_USER=wiki \
  -e DB_NAME=wiki \
  ghcr.io/requarks/wiki:2

Ikke stol på latest etter at ekte data er tatt i bruk. Registrer den fungerende digest-en, containerbrukeren og eierskapet til mountene. Følg applikasjonsloggen gjennom en komplett test — fullfør oppsettet, opprett og rediger en side, last opp medier, søk etter siden og kontroller versjonshistorikken etter en omstart — og noter eventuelle migreringer før ruten legges bak produksj وtrafikk.

Hold interne og eksterne URL-er adskilt

Behandle den eksterne Wiki.js-URL-en som konfigurasjon som skal overleve nye distribusjoner. Konfigurer først site URL etter at tjenesten er rutet gjennom HTTPS. Ruter deretter vertsnavnet til port 3000 med den opprinnelige verten og protokollen intakt.

Sjekklisten for tilgjengelighet ved distribusjon kan bevise at forespørsler kommer inn i containeren. Etter dette bør den kjente feilen — DB_HOST er localhost inne i containeren, eller TLS-proxyheaderne mangler — undersøkes i Wiki.js, tilstanden eller arbeidsbelastningen, ikke i sertifikatautomatiseringen.

Følg med på arbeidsbelastningen, ikke bare containeren

Bygg dashbord rundt svartid for databasen, søkeindeksering, medielagring og forsinkelse hos autentiseringsleverandøren. En CPU-graf uten denne arbeidsbelastningskonteksten kan ikke forklare hvorfor Wiki.js er treg. Legg til en syntetisk eller planlagt kontroll som forsøker å fullføre oppsettet, opprette og redigere en side, laste opp medier, søke etter siden og kontrollere versjonshistorikken etter en omstart ved hjelp av ufarlige testdata.

Før en oppgradering må du ta høyde for denne applikasjonsspesifikke risikoen: Wiki.js-databasemigreringer og autentiseringsmoduler bør fases inn før du går over til en annen release-linje. Gjenopprett en nylig sikkerhetskopi til en isolert distribusjon, kjør migreringene der og sammenlign atferden. Hvis DB_HOST er localhost inne i containeren, eller TLS-proxyheaderne mangler, må du undersøke den aktuelle grensen — offentlig origin, lagring eller avhengighet — før du endrer irrelevante innstillinger.

Hold Wiki.js eksplisitt mens Dockup håndterer ruting

Ruting, sertifikater, utskifting av tjenester og tilknyttet lagring er fornuftige mål for automatisering. Dockup håndterer dette for Wiki.js og kan klargjøre den tilknyttede administrerte databasen eller koble til tjenester på kundens egen server.

Det Dockup ikke bør finne på, er tillitspolicyen for Wiki.js. Etter distribusjon konfigurerer du site URL etter at tjenesten er rutet gjennom HTTPS, håndhever denne grensen — fjern offentlig tilgang til oppsettet, begrens administrasjonen og gi wiki-databasen egne innloggingsopplysninger — og bekrefter resultatet av dette scenariet: fullfør oppsettet, opprett og rediger en side, last opp medier, søk etter siden og kontroller versjonshistorikken etter en omstart. Resultatet er infrastruktur med ett klikk og en applikasjonsspesifikk akseptansetest.

Vanlige spørsmål

Hva trenger Wiki.js for en produksjonsdistribusjon?

Ruter Wiki.js-containeren på port 3000 gjennom én HTTPS-origin. Det støttende nettverkskravet er en tilgjengelig Postgres-, MySQL-, MariaDB-, MSSQL- eller SQLite-database. Ikke regn Wiki.js som klar før du kan fullføre oppsettet, opprette og redigere en side, laste opp medier, søke etter siden og kontrollere versjonshistorikken etter en omstart.

Hvilke Wiki.js-data skal inngå i en sikkerhetskopi?

Standardimaget for Wiki.js har ingen nødvendig mount for applikasjonsdata. Bevar distribusjonskonfigurasjonen og sikkerhetskopier tilknyttet tilstand separat. Gjenopprettingen er godkjent når sider, historikk, brukere, grupper, medier og navigasjon kommer tilbake, og en kjent side fortsatt kan søkes opp.

Krever Wiki.js HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Wiki.js-origin-en, og hold port 3000 på den interne ruten. Bruk Wiki.js-innstillingen riktig: konfigurer site URL etter at tjenesten er rutet gjennom HTTPS. For Wiki.js beskytter HTTPS innloggingsopplysninger og brukerinnhold under overføring, og sørger for at klientatferd som avhenger av origin, forblir konsekvent.

Hvordan bør en Wiki.js-oppgradering testes?

Gjenopprett gjeldende Wiki.js-tilstand til en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at Wiki.js-databasemigreringer og autentiseringsmoduler bør fases inn før du går over til en annen release-linje. Behold det forrige Wiki.js-imaget til grensene for datamigrering og tilbakerulling er forstått.