Slik drifter du DokuWiki selv i 2026: fillagring, ACL-er og sikkerhetskopier

Behandle DokuWiki som et lite system, ikke som et Docker-image. Målet for brukerne av DokuWiki er tydelig: en filbasert wiki som ikke trenger en database. Distribusjonen er først akseptabel når du kan bytte ut oppsettslegitimasjonen, redigere en side, laste opp medier, bruke en ACL, vise en revisjon og gjenopprette en eldre versjon.

Dette skiller ut feilen operatører møter etter lokal testing: Fileierskap hindrer lagring av sider selv om brukergrensesnittet lastes inn. Det gjør også planen for sikkerhetskopiering og oppgradering konkret nok til å testes.

Porter, prosesser og private tjenester

Start med nettverksnavneområdet til DokuWiki: weblytteren bruker port 80, ikke en host-port kopiert fra en laptop-veiledning. Kravet til det lokale runtime-miljøet er et persistent config-volum som inneholder sider, medier og ACL-er. Dokumenter forventet kapasitet, eierskap og feilmåte i stedet for å la dette være en image-standard.

Når kravet er oppfylt, kjører du hele scenarioet – bytt ut oppsettslegitimasjonen, rediger en side, last opp medier, bruk en ACL, vis en revisjon og gjenopprett en eldre versjon. Registrer logger og målinger for filsystemmetadata, medievolum, søkeindeksering og PHP-workers. Disse bevisene blir den første kjente gode arkitekturen og gjør senere flyttinger mellom Dockup-compute og en tilkoblet server testbare.

Feiløvelser for DokuWiki

En grønn container er nødvendig, men ikke tilstrekkelig. Tjenestenivåindikatoren er vellykket gjennomføring av «bytt ut oppsettslegitimasjonen, rediger en side, last opp medier, bruk en ACL, vis en revisjon og gjenopprett en eldre versjon», mens de sannsynlige belastningssignalene er filsystemmetadata, medievolum, søkeindeksering og PHP-workers.

Endringskontroll er viktig fordi plugins og templates kan henge etter DokuWiki-utgivelser, selv om vanlige sidefiler fortsatt kan leses. Bevar det gamle imaget, test migreringer på en kopi av tilstanden og dokumenter om rollback støttes etter at schemaet er flyttet. Hvis fileierskap hindrer lagring av sider selv om brukergrensesnittet lastes inn, må du feilsøke den første grensen som skiller seg fra det fungerende miljøet.

Dokumenter en kjent god DokuWiki-distribusjon

En release candidate for DokuWiki fortjener trafikk når den fullfører et fast scenario: bytt ut oppsettslegitimasjonen, rediger en side, last opp medier, bruk en ACL, vis en revisjon og gjenopprett en eldre versjon. Ta vare på image-digest, effektiv ikke-hemmelig konfigurasjon, offentlig origin og tidspunkter for scenarioet. Testdataene bør kunne kastes, men samtidig være realistiske nok til å bruke samme flyt som brukerne.

Kjør dette etter at runtime-miljøet er byttet ut, og bygg deretter tjenesten på nytt fra sider, medier, metadata, brukere, ACL-er og plugins. Gjenopprettingen er vellykket når sider, revisjoner, medier, brukere, ACL-er og plugins kommer tilbake, og den beskyttede siden fortsatt er beskyttet. Sammenlign ressursmålinger for filsystemmetadata, medievolum, søkeindeksering og PHP-workers med forrige release, og undersøk betydelig avvik før promotering.

Til slutt gjennomfører du denne kontrollerte feilen: send inn ufarlige data nær ressurs- eller formatgrensen som er knyttet til denne grensen: fileierskap hindrer lagring av sider selv om brukergrensesnittet lastes inn. Kontroller at DokuWiki forklarer feilen, ikke skader eksisterende tilstand og fortsetter etter at den gyldige betingelsen er tilbake. Lagre et redigert loggutdrag og gjenopprettingstiden. Til sammen dekker disse kontrollene funksjonalitet, bestandighet og driftbarhet – ikke bare at prosessen er oppe.

Kjør den første produksjonslignende instansen

Bruk en kommando som viser alle viktige valg. Denne grunnkonfigurasjonen binder DokuWiki til loopback på hosten, legger til de kjente datamonteringene og angir den første nødvendige innstillingen. Bekreft det lokale kravet før eksponering: et persistent config-volum som inneholder sider, medier og ACL-er.

docker run -d \
  --name dokuwiki \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v dokuwiki-data:/config \
  lscr.io/linuxserver/dokuwiki:latest

Bytt ut flytende tags med en testet versjon eller digest. Etter oppstart inspiserer du docker logs --tail 200 dokuwiki og bekrefter at prosessen lytter på port 80. Kjør deretter DokuWiki-akseptansetesten. Et svar fra root-siden kan ikke bevise at hele scenarioet lykkes: bytt ut oppsettslegitimasjonen, rediger en side, last opp medier, bruk en ACL, vis en revisjon og gjenopprett en eldre versjon.

Volumer er bare det første laget for gjenoppretting

For DokuWiki begynner sikker redeploy med sider, medier, metadata, brukere, ACL-er og plugins. Monter /config før bootstrap, skriv ufarlige eksempeldata og bytt ut containeren for å bevise at denne banen faktisk er persistent. Test banen ved å bytte ut containeren mens ufarlige eksempeldata fortsatt finnes. Dette avdekker mounts som peker én katalog for høyt eller lavt.

Test deretter disaster recovery på en tom host. Bruk en applikasjonskonsistent databaseeksport når det er nødvendig, og bekreft at sider, revisjoner, medier, brukere, ACL-er og plugins kommer tilbake, og at den beskyttede siden fortsatt er beskyttet. Veiledningen om sikkerhetskopier av databaser som er testet ved gjenoppretting gir et bedre mål enn å bare kontrollere at en arkivfil ble opprettet.

Gi DokuWiki én kanonisk adresse

TLS-utstedelse er bare halvparten av DokuWiki-ruten. Server w ikien over HTTPS og angi den kanoniske base-URL-en. Send trafikken internt til port 80, og videresend det eksterne scheme-et slik at genererte URL-er og sikre cookies forblir konsistente.

Bruk hele DokuWiki-scenarioet fra et rent nettverk, ikke bare root-siden. En 502-feil eller sertifikatfeil kan isoleres med automatisk oppsett av domene og TLS. Hvis trafikken når prosessen og fileierskap hindrer lagring av sider selv om brukergrensesnittet lastes inn, må du feilsøke tilstanden der den oppstår i stedet for å legge flere redirects oppå hverandre.

Lukk midlertidig oppsettstilgang

Trusselmodeller handlingen DokuWiki utfører, ikke bare innloggingsskjemaet. Den store risikoen her er å la installerings- eller registreringsinnstillinger stå åpne. Implementer denne grensen: fjern tilgang til installasjonsprogrammet, gå gjennom registreringen og bevar ACL-filer sammen med sideinnholdet.

DokuWiki har ingen obligatorisk bootstrap-hemmelighet i denne grunnkonfigurasjonen. Beskytt i stedet den faktiske administratorkontoen eller autentiseringen oppstrøms. Ikke løs en tillatelsesfeil ved å kjøre containeren som root eller montere hosten bredt. Ressursgrenser hører også hjemme i sikkerhetsdesignet når filsystemmetadata, medievolum, søkeindeksering og PHP-workers kan utløses av brukere.

Bruk Dockup for plattformlaget

En Dockup-mal bør angi image, port 80, mounts, helsesjekktiming, domene, TLS og levering av secrets. Dockup bør bevare runtime-innstillingene for DokuWiki, mens operatøren bekrefter dette lokale kravet: et persistent config-volum som inneholder sider, medier og ACL-er. Den samme distribusjonen kan målrettes mot Dockup-servere eller kapasitet tilkoblet av kunden.

Når ruten er aktiv, bruker du den offentlige innstillingen og prøver å bytte ut oppsettslegitimasjonen, redigere en side, laste opp medier, bruke en ACL, vise en revisjon og gjenopprette en eldre versjon. Sikkerhetskopier sider, medier, metadata, brukere, ACL-er og plugins, og behold gjenopprettingsøvelsen i driftsplanen. Dette er DokuWiki-ansvar som fortsatt er synlig etter at infrastrukturen er klargjort.

Ofte stilte spørsmål

Hva trenger DokuWiki for en produksjonsdistribusjon?

Rout DokuWiki-containeren på port 80 gjennom én HTTPS-origin. Kravet til det lokale runtime-miljøet er et persistent config-volum som inneholder sider, medier og ACL-er. Ikke erklær DokuWiki klar før du kan bytte ut oppsettslegitimasjonen, redigere en side, laste opp medier, bruke en ACL, vise en revisjon og gjenopprette en eldre versjon.

Hvilke DokuWiki-data bør inngå i en sikkerhetskopi?

Gjør /config persistent, og inkluder sider, medier, metadata, brukere, ACL-er og plugins i det samme gjenopprettingsmanifestet. En ren DokuWiki-gjenoppretting er bare vellykket når sider, revisjoner, medier, brukere, ACL-er og plugins kommer tilbake, og den beskyttede siden fortsatt er beskyttet.

Krever DokuWiki HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige DokuWiki-originen, og behold port 80 på den interne ruten. Bruk DokuWiki-innstillingen riktig: server w ikien over HTTPS og angi den kanoniske base-URL-en. For DokuWiki beskytter HTTPS legitimasjon eller brukerinnhold under overføring og sørger for konsistent klientatferd som er avhengig av origin.

Hvordan bør en DokuWiki-oppgradering testes?

Gjenopprett den gjeldende DokuWiki-tilstanden i en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom fordi plugins og templates kan henge etter DokuWiki-utgivelser, selv om vanlige sidefiler fortsatt kan leses. Behold det forrige DokuWiki-imaget til grensen for datamigrering og rollback er forstått.