Sådan selvhoster du DokuWiki i 2026: Fillagring, ACL'er og backups
En praktisk guide til selvhosting af DokuWiki med fokus på Docker, porte, persistent data, TLS, sikkerhed, backups og de fejl, der forhindrer produktionsbrug. Med checks.
Betragt DokuWiki som et lille system, ikke som et Docker-image. Det brugerrettede mål for DokuWiki er klart: en filbaseret wiki, der ikke kræver en database. Deployeringen er først acceptabel, når du kan udskifte opsætningsoplysningerne, redigere en side, uploade medier, anvende en ACL, se en revision og gendanne en ældre version.
Den forskel afslører den fejltilstand, operatører møder efter lokal test: Filejerskab forhindrer lagring af sider, selv om brugerfladen indlæses. Den gør også backup- og upgrade-planen tilstrækkeligt specifik til, at den kan testes.
Porte, processer og private services
Start med DokuWikis netværksnamespace: dens web listener kører på port 80, ikke på en host-port kopieret fra en laptop-tutorial. Det lokale runtime-krav er et persistent config-volume, der indeholder sider, medier og ACL'er. Dokumentér den forventede kapacitet, ejerskab og fejltilstand i stedet for at lade det være et image-default.
Når kravet er opfyldt, skal du køre hele scenariet — udskift opsætningsoplysningerne, rediger en side, upload medier, anvend en ACL, se en revision og gendan en ældre version. Registrér logs og målinger for filesystem-metadata, medievolumen, search indexing og PHP workers. Disse data bliver den første kendte fungerende arkitektur og gør senere flytninger mellem Dockup compute og en tilknyttet server testbare.
Fejløvelser for DokuWiki
En grøn container er nødvendig, men ikke tilstrækkelig. Service-level-indikatoren er, om “udskift opsætningsoplysningerne, rediger en side, upload medier, anvend en ACL, se en revision og gendan en ældre version” gennemføres korrekt, mens de sandsynlige belastningssignaler er filesystem-metadata, medievolumen, search indexing og PHP workers.
Change control er vigtigt, fordi plugins og templates kan være bagefter DokuWiki-releases, selv om almindelige sidefiler stadig kan læses. Bevar det gamle image, test migrationer på en kopi af state, og dokumentér, om rollback understøttes, efter at schemaet er flyttet. Hvis filejerskab forhindrer lagring af sider, selv om brugerfladen indlæses, skal du diagnosticere den første boundary, der adskiller sig fra det fungerende miljø.
Dokumentér en kendt fungerende DokuWiki-deployment
En release candidate til DokuWiki fortjener trafik ved at gennemføre et fast scenarie: udskift opsætningsoplysningerne, rediger en side, upload medier, anvend en ACL, se en revision og gendan en ældre version. Registrér image digest, effektiv ikke-hemmelig konfiguration, public origin og tidsstempler for scenariet. Testdataene skal kunne kasseres, men være realistiske nok til at afprøve den samme sti som brugerne.
Kør testen efter udskiftning af runtime, og genopbyg derefter servicen fra sider, medier, metadata, brugere, ACL'er og plugins. Recovery er godkendt, når sider, revisioner, medier, brugere, ACL'er og plugins er tilbage, og den beskyttede side stadig er beskyttet. Sammenlign resourcemålinger for filesystem-metadata, medievolumen, search indexing og PHP workers med den tidligere release, og undersøg betydelige afvigelser før promotion.
Afslut med denne kontrollerede fejl: indsend harmløst input tæt på den ressource- eller formatgrænse, der er knyttet til denne boundary: filejerskab forhindrer lagring af sider, selv om brugerfladen indlæses. Kontrollér, at DokuWiki forklarer fejlen, ikke beskadiger eksisterende state og genoptager driften, når den gyldige tilstand vender tilbage. Gem et redigeret logudsnit og recovery-tiden. Tilsammen dækker disse checks adfærd, durability og operability i stedet for kun processens uptime.
Kør den første produktionslignende instans
Brug en kommando, der eksponerer alle vigtige valg. Denne baseline binder DokuWiki til hostens loopback, tilføjer de kendte data mounts og leverer den første påkrævede indstilling. Bekræft det lokale krav før eksponering: et persistent config-volume, der indeholder 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
Erstat floating tags med en testet version eller digest. Efter opstart skal du inspicere docker logs --tail 200 dokuwiki og bekræfte, at processen lytter på port 80. Udfør derefter DokuWikis acceptance action. Et svar fra root-siden kan ikke dokumentere, at hele scenariet lykkes: udskift opsætningsoplysningerne, rediger en side, upload medier, anvend en ACL, se en revision og gendan en ældre version.
Volumes er kun det første recovery-lag
For DokuWiki begynder sikker redeploy med sider, medier, metadata, brugere, ACL'er og plugins. Mount /config før bootstrap, skriv harmløse eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Test stien ved at udskifte containeren, mens de harmløse eksempeldata stadig findes. Det afslører mounts, der peger en mappe for højt eller lavt.
Test derefter disaster recovery på en tom host. Brug en application-consistent database export, hvor det er nødvendigt, og kontrollér, at sider, revisioner, medier, brugere, ACL'er og plugins kommer tilbage, og at den beskyttede side stadig er beskyttet. Guiden restore-tested database backup angiver et stærkere mål end blot at kontrollere, at der blev oprettet en archive-fil.
Giv DokuWiki én canonical adresse
TLS-udstedelse er kun halvdelen af DokuWiki-routen. Servér wikien over HTTPS, og angiv dens canonical base URL. Send trafikken internt til port 80, og forward det eksterne scheme, så genererede URLs og secure cookies forbliver konsistente.
Brug det komplette DokuWiki-scenarie fra et rent netværk, ikke kun root-siden. En 502- eller certifikatfejl kan isoleres med automatisk opsætning af domæne og TLS. Hvis trafikken når processen, og filejerskab forhindrer lagring af sider, selv om brugerfladen indlæses, skal du diagnosticere tilstanden dér, hvor den opstår, i stedet for at stable redirects oven på hinanden.
Luk midlertidig adgang til opsætning
Threat-model den handling, DokuWiki udfører, ikke kun dens loginformular. Den store risiko her er at lade installer eller registration settings stå åbne. Implementér denne boundary: fjern adgang til installer, gennemgå registration, og bevar ACL-filer sammen med sideindholdet.
DokuWiki har ingen obligatorisk bootstrap-secret i denne baseline. Beskyt i stedet den faktiske administratorkonto eller upstream authentication. Løs ikke en permission error ved at køre containeren som root eller mounte hosten bredt. Resource limits hører også til i sikkerhedsdesignet, når brugere kan udløse filesystem-metadata, medievolumen, search indexing og PHP workers.
Brug Dockup til platformlaget
En Dockup-template bør indeholde image, port 80, mounts, health timing, domæne, TLS og secret delivery. Dockup skal bevare DokuWikis runtime-indstillinger, mens operatøren bekræfter dette lokale krav: et persistent config-volume, der indeholder sider, medier og ACL'er. Den samme deployment kan målrettes Dockup-servere eller kundetilknyttet kapacitet.
Når routen er live, skal du anvende den offentlige indstilling og forsøge at udskifte opsætningsoplysningerne, redigere en side, uploade medier, anvende en ACL, se en revision og gendanne en ældre version. Tag backup af sider, medier, metadata, brugere, ACL'er og plugins, og behold restore-øvelsen i driftsplanen. Det er DokuWiki-ansvar, som stadig er synligt, efter at infrastrukturen er provisioneret.
Ofte stillede spørgsmål
Hvad kræver DokuWiki til en produktionsdeployment?
Route DokuWiki-containeren på port 80 gennem én HTTPS-origin. Det lokale runtime-krav er et persistent config-volume, der indeholder sider, medier og ACL'er. Kald ikke DokuWiki klar, før du kan udskifte opsætningsoplysningerne, redigere en side, uploade medier, anvende en ACL, se en revision og gendanne en ældre version.
Hvilke DokuWiki-data skal med i en backup?
Gør /config persistent, og medtag sider, medier, metadata, brugere, ACL'er og plugins i det samme recovery-manifest. En ren DokuWiki-restore er kun godkendt, når sider, revisioner, medier, brugere, ACL'er og plugins er tilbage, og den beskyttede side stadig er beskyttet.
Kræver DokuWiki HTTPS bag en reverse proxy?
Brug HTTPS for den offentlige DokuWiki-origin, og behold port 80 på den interne route. Anvend DokuWiki-indstillingen korrekt: servér wikien over HTTPS, og angiv dens canonical base URL. For DokuWiki beskytter HTTPS credentials eller brugerindhold under transport og holder origin-følsom client-adfærd konsistent.
Hvordan skal en DokuWiki-upgrade testes?
Gendan den aktuelle DokuWiki-state i en isoleret deployment, anvend kandidatversionen, og gentag dens acceptance transaction. Vær særligt opmærksom, fordi plugins og templates kan være bagefter DokuWiki-releases, selv om almindelige sidefiler stadig kan læses. Behold det tidligere DokuWiki-image, indtil dets data-migration- og rollback-boundary er forstået.