A DokuWiki saját üzemeltetése 2026-ban: fájltárolás, ACL-ek és biztonsági mentések

A DokuWikit kezeld kisebb rendszerként, ne csupán Docker image-ként. A DokuWiki felhasználói célja egyértelmű: adatbázist nem igénylő, fájlalapú wiki; a deployment csak akkor tekinthető elfogadhatónak, ha le tudod cserélni a telepítési hitelesítő adatokat, szerkeszteni tudsz egy oldalt, fel tudsz tölteni médiát, alkalmazni tudsz egy ACL-t, meg tudsz nézni egy revíziót, és vissza tudsz állítani egy korábbi verziót.

Ez a különbségtétel felszínre hozza azt a hibamódot, amellyel az üzemeltetők a lokális tesztelés után találkoznak: a fájltulajdonjog megakadályozza az oldalak mentését, miközben a UI betöltődik. Emellett a backup- és upgrade-terv is elég konkréttá válik ahhoz, hogy tesztelni lehessen.

Portok, folyamatok és privát szolgáltatások

Kezdd a DokuWiki network namespace-ével: a webes listener a 80-as porton működik, nem egy laptopos tutorialból átmásolt host porton. A lokális runtime-követelmény egy perzisztens config volume, amely az oldalakat, a médiát és az ACL-eket tartalmazza. Az elvárt kapacitást, a tulajdonjogot és a hibamódot dokumentáld, ahelyett hogy mindent az image alapértelmezéseire bíznál.

A követelmény teljesülése után futtasd végig a teljes szcenáriót — cseréld le a telepítési hitelesítő adatokat, szerkessz egy oldalt, tölts fel médiát, alkalmazz egy ACL-t, nézz meg egy revíziót, és állíts vissza egy korábbi verziót. Rögzítsd a fájlrendszer-metaadatokra, a médiakötettre, a keresési indexelésre és a PHP workerekre vonatkozó logokat és méréseket. Ez a bizonyíték lesz az első ismert, megfelelően működő architektúra, és tesztelhetővé teszi a későbbi átállásokat a Dockup compute-erőforrásai és egy csatlakoztatott szerver között.

Hibagyakorlatok DokuWikihoz

A zöld container szükséges, de önmagában nem elégséges. A service-level indicator a „telepítési hitelesítő adatok lecserélése, egy oldal szerkesztése, média feltöltése, ACL alkalmazása, egy revízió megtekintése és egy korábbi verzió visszaállítása” műveletsor sikeres befejezése, míg a várható terhelési jelek a fájlrendszer-metaadatok, a médiakötet, a keresési indexelés és a PHP workerek.

A change control azért fontos, mert a pluginek és a template-ek lemaradhatnak a DokuWiki kiadásaihoz képest, miközben az egyszerű oldal-fájlok továbbra is olvashatók maradnak. Őrizd meg a régi image-et, a migrációkat másolt állapoton teszteld, és dokumentáld, hogy támogatott-e a rollback a séma módosulása után. Ha a fájltulajdonjog megakadályozza az oldalak mentését, miközben a UI betöltődik, azt az első, működő környezettől eltérő határfelületen diagnosztizáld.

Rögzíts egy ismert, megfelelően működő DokuWiki-deploymentet

A DokuWiki release candidate-je akkor kaphat forgalmat, ha teljesít egy rögzített szcenáriót: a telepítési hitelesítő adatok lecserélését, egy oldal szerkesztését, média feltöltését, egy ACL alkalmazását, egy revízió megtekintését és egy korábbi verzió visszaállítását. Rögzítsd az image digestjét, a tényleges, nem titkos konfigurációt, a publikus origint és a szcenárió időbélyegeit. A tesztadatok legyenek eldobhatók, de elég realisták ahhoz, hogy ugyanazt az útvonalat gyakorolják, mint a felhasználók.

Futtasd le ezt a runtime lecserélése után, majd építsd újra a szolgáltatást az oldalakból, a médiából, a metaadatokból, a felhasználókból, az ACL-ekből és a pluginekből. A helyreállítás akkor sikeres, ha az oldalak, a revíziók, a média, a felhasználók, az ACL-ek és a pluginek visszatérnek, és a védett oldal továbbra is védett marad. Hasonlítsd össze a fájlrendszer-metaadatokra, a médiakötettre, a keresési indexelésre és a PHP workerekre vonatkozó erőforrás-méréseket az előző kiadás értékeivel, és a promotion előtt vizsgáld ki az érdemi eltéréseket.

Végül hajtsd végre ezt az ellenőrzött hibát: küldj ártalmatlan inputot a következő határhoz tartozó erőforrás- vagy formátumlimit közelében: a fájltulajdonjog megakadályozza az oldalak mentését, miközben a UI betöltődik. Ellenőrizd, hogy a DokuWiki érthetően jelzi a hibát, nem károsítja a meglévő állapotot, és a helyes feltétel visszatérése után folytatja a működést. Ments el egy redaktált logrészletet és a helyreállítási időt. Ezek az ellenőrzések együtt a viselkedést, a tartósságot és az üzemeltethetőséget fedik le, nem csupán a process uptime-ját.

Futtasd az első production jellegű példányt

Olyan parancsot használj, amely minden fontos választást láthatóvá tesz. Ez az alapkonfiguráció a DokuWikit a host loopback interfészéhez köti, felveszi az ismert adatmountokat, és megadja az első szükséges beállítást. Exponálás előtt erősítsd meg a lokális követelményt: egy perzisztens config volume-ot, amely az oldalakat, a médiát és az ACL-eket tartalmazza.

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

A floating tageket cseréld tesztelt verzióra vagy dig estre. Indítás után vizsgáld meg a docker logs --tail 200 dokuwiki kimenetét, és erősítsd meg, hogy a process a 80-as porton figyel. Ezután hajtsd végre a DokuWiki acceptance műveletét; egy root-page válasza nem bizonyítja, hogy a teljes szcenárió sikeres: a telepítési hitelesítő adatok lecserélését, egy oldal szerkesztését, média feltöltését, egy ACL alkalmazását, egy revízió megtekintését és egy korábbi verzió visszaállítását.

A volume-ok csak a helyreállítás első rétegét jelentik

A DokuWiki esetében a redeploy biztonsága az oldalakkal, a médiával, a metaadatokkal, a felhasználókkal, az ACL-ekkel és a pluginekkel kezdődik. A bootstrap előtt csatold a /config könyvtárat, írj bele ártalmatlan mintaadatokat, majd cseréld le a containert annak bizonyítására, hogy az útvonal valóban perzisztens. Teszteld az útvonalat úgy, hogy lecseréled a containert, miközben az ártalmatlan mintaadatok még léteznek; ez felszínre hozza azokat a mountokat, amelyek egy könyvtárral túl magasra vagy túl alacsonyra mutatnak.

Ezután teszteld a disaster recovery folyamatot egy üres hoston. Ahol szükséges, használj alkalmazáskonzisztens database exportot, majd ellenőrizd, hogy az oldalak, a revíziók, a média, a felhasználók, az ACL-ek és a pluginek visszatérnek, és a védett oldal továbbra is védett marad. A restore-tested database backup útmutató erősebb célt ad annál, mint pusztán ellenőrizni, hogy létrejött-e egy archive fájl.

Adj a DokuWikinek egy kanonikus címet

A TLS kiállítása csak a DokuWiki útvonalának egyik fele. A wikit HTTPS-en szolgáld ki, és állítsd be a kanonikus base URL-jét. A forgalmat belsőleg a 80-as portra irányítsd, és továbbítsd a külső scheme-et, hogy a generált URL-ek és a secure cookie-k konzisztensak maradjanak.

A teljes DokuWiki-szcenáriót tiszta hálózatról futtasd, ne csupán a root oldalt ellenőrizd. A 502-es vagy tanúsítványhibát az automatikus domain- és TLS-beállítással különítheted el. Ha a forgalom eléri a processt, és a fájltulajdonjog megakadályozza az oldalak mentését, miközben a UI betöltődik, a feltételt ott diagnosztizáld, ahol jelentkezik, ahelyett hogy redirecteket halmoznál egymásra.

Zárd le az ideiglenes setup-hozzáférést

A fenyegetési modellt arra a műveletre készítsd, amelyet a DokuWiki végrehajt, ne csak a login formra. Itt az a nagy kockázatú hiba, ha nyitva marad az installer vagy a regisztrációs beállítások. Alakítsd ki ezt a határvonalat: távolítsd el az installer-hozzáférést, vizsgáld felül a regisztrációt, és az ACL-fájlokat az oldal tartalmával együtt őrizd meg.

A DokuWikinek ebben az alapkonfigurációban nincs kötelező bootstrap secretje; ehelyett védd a tényleges administrator accountot vagy az upstream authenticationt. Ne úgy oldj meg egy permission errort, hogy rootként futtatod a containert, vagy széles körű host mountot használsz. Az erőforráslimitek szintén a security design részét képezik, amikor a felhasználók fájlrendszer-metaadatokat, médiakötetet, keresési indexelést és PHP workereket válthatnak ki.

Használd a Dockupot a platformréteghez

Egy Dockup template-nek kell kódolnia az image-et, a 80-as portot, a mountokat, a health timingot, a domaint, a TLS-t és a secret deliveryt. A Dockup őrizze meg a DokuWiki runtime-beállításait, miközben az üzemeltető megerősíti ezt a lokális követelményt: egy perzisztens config volume-ot, amely az oldalakat, a médiát és az ACL-eket tartalmazza. Ugyanaz a deployment célozhat Dockup-szervereket vagy ügyfél által csatlakoztatott kapacitást.

Az útvonal élesítése után alkalmazd a publikus beállítást, és próbáld meg lecserélni a telepítési hitelesítő adatokat, szerkeszteni egy oldalt, feltölteni médiát, alkalmazni egy ACL-t, megtekinteni egy revíziót és visszaállítani egy korábbi verziót. Készíts biztonsági mentést az oldalakról, a médiáról, a metaadatokról, a felhasználókról, az ACL-ekről és a pluginekről, és tartsd meg a restore-gyakorlatot az üzemeltetési tervben; ezek olyan DokuWiki-felelősségek, amelyek az infrastruktúra provisioningje után is láthatók maradnak.

Gyakran ismételt kérdések

Mire van szüksége a DokuWikinek production deploymenthez?

A DokuWiki containert egyetlen HTTPS originön keresztül irányítsd a 80-as portra. A lokális runtime-követelmény egy perzisztens config volume, amely az oldalakat, a médiát és az ACL-eket tartalmazza. Ne tekintsd késznek a DokuWikit addig, amíg le nem tudod cserélni a telepítési hitelesítő adatokat, nem tudsz szerkeszteni egy oldalt, feltölteni médiát, alkalmazni egy ACL-t, megtekinteni egy revíziót és visszaállítani egy korábbi verziót.

Mely DokuWiki-adatoknak kell szerepelniük a backupban?

A /config könyvtárat tedd perzisztenssé, és ugyanabba a recovery manifestbe vedd fel az oldalakat, a médiát, a metaadatokat, a felhasználókat, az ACL-eket és a plugineket. A tiszta DokuWiki-restore csak akkor sikeres, ha az oldalak, a revíziók, a média, a felhasználók, az ACL-ek és a pluginek visszatérnek, és a védett oldal továbbra is védett marad.

Szüksége van a DokuWikinek HTTPS-re reverse proxy mögött?

A publikus DokuWiki origint HTTPS-en használd, a belső útvonalon pedig tartsd meg a 80-as portot. Helyesen alkalmazd a DokuWiki-beállítást: a wikit HTTPS-en szolgáld ki, és állítsd be a kanonikus base URL-jét. A DokuWiki esetében a HTTPS védi a hitelesítő adatokat és a felhasználói tartalmat átvitel közben, valamint konzisztenssé teszi az origintől függő kliensviselkedést.

Hogyan kell tesztelni egy DokuWiki-upgrade-et?

Állítsd vissza a jelenlegi DokuWiki-állapotot egy izolált deploymentbe, alkalmazd a jelölt verziót, és ismételd meg az acceptance tranzakciót. Különösen figyelj erre, mert a pluginek és a template-ek lemaradhatnak a DokuWiki kiadásaihoz képest, miközben az egyszerű oldal-fájlok továbbra is olvashatók maradnak. Tartsd meg a korábbi DokuWiki image-et mindaddig, amíg nem tisztázott az adat-migrációs és rollback-határa.