Ako hostovať Wiki.js vo vlastnej réžii v roku 2026: Nastavenie databázy, TLS a testy obnovy

Väčšina návodov na inštaláciu Wiki.js končí pri prvom načítaní stránky. To je príliš skoro: DB_HOST je v kontajneri nastavený na localhost alebo chýbajú hlavičky proxy pre TLS. Užitočný produkčný test je náročnejší — dokončite nastavenie, vytvorte a upravte stránku, nahrajte médiá, vyhľadajte ich a po reštarte skontrolujte históriu verzií.

Úloha Wiki.js je jednoduchá: Markdown wiki s verzovaním a moderným editorom. Jej prevádzková hranica zahŕňa viac než len webový proces, preto treba pred príchodom skutočných dát explicitne pomenovať závislosť, ukladaný stav aj verejnú route.

Vymedzte runtime hranicu Wiki.js

Najmenšia zodpovedná topológia Wiki.js obsahuje jeden privátny listener na porte 3000, ingress route a zdokumentovanú hranicu stavu. Sieťová zmluva pre Wiki.js je dostupná databáza Postgres, MySQL, MariaDB, MSSQL alebo SQLite. Privátne endpointy ponechajte na internom DNS, povoľte iba potrebné odchádzajúce volania a Wiki.js prideľte service credential s obmedzeným rozsahom oprávnení.

Topológiu overte tak, že čistému klientovi umožníte dokončiť nastavenie, vytvoriť a upraviť stránku, nahrať médiá, vyhľadať ich a po reštarte skontrolovať históriu verzií. Počas behu sledujte čas odozvy databázy, indexovanie vyhľadávania, úložisko médií a latenciu poskytovateľa autentifikácie. Výsledok vám ukáže, či ďalšie zlepšenie patrí do oblasti pamäte, úložiska, siete alebo samostatného workera, namiesto náhodného dimenzovania kontajnera.

Navrhnite obnovu Wiki.js ešte pred spustením

V štandardnom obraze Wiki.js sa neočakáva žiadny zapisovateľný stav aplikácie. Zachovajte databázu spolu s lokálnymi uploadmi a vlastnými assetmi vrátane pripnutého digestu a skontrolovanej konfigurácie routy, namiesto zálohovania prázdneho filesystemu kontajnera.

Vytvorte Wiki.js od začiatku na inom hoste a overte, že sa vrátia stránky, história, používatelia, skupiny, médiá a navigácia a že známu stránku možno naďalej vyhľadať. Ak pridáte samostatnú databázu, room server alebo autentifikačnú vrstvu, prideľte tomuto komponentu vlastného explicitného vlastníka obnovy. Návod od repozitára po produkciu ukazuje, ako reprodukovateľný artifact nahrádza zálohu kontajnera.

Príkaz na rebuild a test so známym výstupom zaznamenajte spolu s release. Bezstavový plán obnovy je úspešný vtedy, keď reprodukuje správanie z dôveryhodných vstupov; nemal by závisieť od kopírovania nepriehľadného bežiaceho kontajnera.

Zvoľte hranicu dôvery Wiki.js

Bezpečné nasadenie Wiki.js začína odstránením nadbytočných oprávnení. Po vytvorení prvého administrátora nenechávajte obrazovku nastavenia verejne dostupnú; namiesto toho odstráňte verejný prístup k nastaveniu, obmedzte administráciu a databáze wiki prideľte vlastné prihlasovacie údaje.

S DB_PASS zaobchádzajte podľa jeho úlohy vo Wiki.js: citlivé hodnoty uchovávajte mimo Git, zdokumentujte dôsledky rotácie a v produkcii nikdy nepoužívajte verejný príklad. Obmedzte administratívne routy, pre závislosti používajte privátny DNS a skontrolujte každý bind mount. Keď sa logy odosielajú centrálne, pred opustením servera z nich odfiltrujte secrets a súkromný obsah.

Čo musí prejsť pred príchodom skutočných dát Wiki.js

Produkčný gate pre Wiki.js by mal vedieť spustiť človek, ktorý nasadenie nevytváral. Dajte mu pripnutú verziu, testovací účet bez citlivých údajov a túto úlohu: dokončite nastavenie, vytvorte a upravte stránku, nahrajte médiá, vyhľadajte ich a po reštarte skontrolujte históriu verzií. Ak pokyny vyžadujú nezdokumentovaný shell access, služba ešte nie je prevádzkovo pripravená.

Gate zopakujte po nahradení iba kontajnera. Potom obnovte databázu spolu s lokálnymi uploadmi a vlastnými assetmi do prázdnej infraštruktúry a dokážte, že sa vrátia stránky, história, používatelia, skupiny, médiá a navigácia a že známu stránku možno naďalej vyhľadať. Počas oboch úspešných behov merajte čas odozvy databázy, indexovanie vyhľadávania, úložisko médií a latenciu poskytovateľa autentifikácie; neočakávané rozdiely často odhalia chýbajúcu cache, index, workera alebo mount s dátami.

Pridajte aj failure drill: dočasne odoberte testovacej identite prístup k dostupnej databáze Postgres, MySQL, MariaDB, MSSQL alebo SQLite. Wiki.js by mal vypísať užitočnú chybu, zachovať existujúci stav a po obnovení platnej podmienky sa zotaviť. Uložte časové pečiatky a relevantné riadky logu so začiernenými secrets. Tieto dôkazy sa stanú referenciou pre ďalšiu zmenu obrazu alebo konfigurácie.

Spustite Wiki.js bez skrývania pohyblivých častí

Počiatočné spustenie Wiki.js udržujte dostatočne reprodukovateľné na kontrolu v pull requeste.

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

Po príchode skutočných dát sa nespoliehajte na latest. Zachyťte funkčný digest, používateľa kontajnera a vlastníctvo mountov. Sledujte log aplikácie počas kompletného testu — dokončite nastavenie, vytvorte a upravte stránku, nahrajte médiá, vyhľadajte ich a po reštarte skontrolujte históriu verzií — a pred presmerovaním routy na produkčnú prevádzku si poznačte prípadné migrácie.

Udržujte interné a externé URL oddelené

Externú URL Wiki.js považujte za konfiguráciu, ktorá musí prežiť redeploy. Najprv po presmerovaní služby cez HTTPS nakonfigurujte URL lokality; potom nasmerujte hostname na port 3000 so zachovaným pôvodným hostom a schémou.

Checklist dostupnosti nasadenia môže dokázať, že požiadavky vstupujú do kontajnera. Od tohto bodu treba známu chybu — DB_HOST je v kontajneri localhost alebo chýbajú hlavičky proxy pre TLS — hľadať vo Wiki.js, jeho stave alebo workload, nie v automatizácii certifikátov.

Sledujte workload, nielen kontajner

Dashboardy vytvárajte okolo času odozvy databázy, indexovania vyhľadávania, úložiska médií a latencie poskytovateľa autentifikácie. Graf CPU bez kontextu workloadu nedokáže vysvetliť, prečo je Wiki.js pomalý. Pridajte syntetickú alebo plánovanú kontrolu, ktorá sa pomocou neškodných testovacích dát pokúsi dokončiť nastavenie, vytvoriť a upraviť stránku, nahrať médiá, vyhľadať ich a po reštarte skontrolovať históriu verzií.

Pred aktualizáciou zohľadnite toto špecifické riziko aplikácie: databázové migrácie Wiki.js a autentifikačné moduly treba pripraviť vopred pred prechodom na inú release líniu. Obnovte nedávnu zálohu do izolovaného nasadenia, spustite tam migrácie a porovnajte správanie. Ak je DB_HOST v kontajneri localhost alebo chýbajú hlavičky proxy pre TLS, pred úpravou nesúvisiacich nastavení skontrolujte príslušnú hranicu — verejný origin, úložisko alebo závislosť.

Udržujte Wiki.js explicitný, zatiaľ čo Dockup spravuje routing

Routing, certifikáty, výmena služieb a pripojené úložisko sú rozumné ciele automatizácie. Dockup ich pre Wiki.js spravuje a môže tiež pripraviť súvisiacu managed databázu alebo sa pripojiť k službám na vlastnom serveri zákazníka.

Nemal by však vymýšľať politiku dôvery Wiki.js. Po nasadení nakonfigurujte URL lokality po presmerovaní služby cez HTTPS, vynúťte túto hranicu — odstráňte verejný prístup k nastaveniu, obmedzte administráciu a databáze wiki prideľte vlastné prihlasovacie údaje — a overte výsledok tohto scenára: dokončite nastavenie, vytvorte a upravte stránku, nahrajte médiá, vyhľadajte ich a po reštarte skontrolujte históriu verzií. Výsledkom je infraštruktúra na jedno kliknutie s akceptačným testom špecifickým pre aplikáciu.

Často kladené otázky

Čo Wiki.js potrebuje na produkčné nasadenie?

Kontajner Wiki.js na porte 3000 smerujte cez jeden HTTPS origin. Podporovanou sieťovou požiadavkou je dostupná databáza Postgres, MySQL, MariaDB, MSSQL alebo SQLite. Wiki.js nepovažujte za pripravený, kým nedokážete dokončiť nastavenie, vytvoriť a upraviť stránku, nahrať médiá, vyhľadať ich a po reštarte skontrolovať históriu verzií.

Ktoré dáta Wiki.js patria do zálohy?

Štandardný obraz Wiki.js nemá povinný mount s dátami aplikácie. Zachovajte jeho konfiguráciu nasadenia a každý pripojený stav zálohujte samostatne; obnova je úspešná, keď sa vrátia stránky, história, používatelia, skupiny, médiá a navigácia a známu stránku možno naďalej vyhľadať.

Vyžaduje Wiki.js HTTPS za reverse proxy?

Pre verejný origin Wiki.js používajte HTTPS a port 3000 ponechajte na internej route. Nastavenie Wiki.js aplikujte správne: po presmerovaní služby cez HTTPS nakonfigurujte URL lokality. V prípade Wiki.js HTTPS chráni prihlasovacie údaje alebo používateľský obsah pri prenose a udržiava konzistentné správanie klienta závislé od originu.

Ako testovať aktualizáciu Wiki.js?

Obnovte aktuálny stav Wiki.js do izolovaného nasadenia, aplikujte kandidátnu verziu a zopakujte akceptačnú transakciu. Venujte tomu mimoriadnu pozornosť, pretože databázové migrácie Wiki.js a autentifikačné moduly treba pripraviť vopred pred prechodom na inú release líniu. Predchádzajúci obraz Wiki.js si ponechajte, kým nebudete rozumieť hranici migrácie dát a rollbacku.