Jak provozovat Wiki.js ve vlastní režii v roce 2026: nastavení databáze, TLS a testy obnovy

Většina návodů k instalaci Wiki.js končí u prvního načtení stránky. To je příliš brzy: DB_HOST je uvnitř kontejneru nastavený na localhost nebo chybí hlavičky TLS proxy. Užitečný produkční test je náročnější — dokončit nastavení, vytvořit a upravit stránku, nahrát média, vyhledat je a po restartu zkontrolovat historii verzí.

Úloha Wiki.js je přímočará: Markdown wiki s verzováním a moderním editorem. Její provozní hranice zahrnuje víc než jen webový proces, takže před příchodem skutečných dat musíte explicitně pojmenovat závislost, uložený stav i veřejnou route.

Vymezte hranice runtime Wiki.js

Nejmenší odpovědná topologie Wiki.js obsahuje jeden privátní listener na portu 3000, ingress route a zdokumentovanou hranici stavu. Síťový kontrakt Wiki.js představuje dostupná databáze Postgres, MySQL, MariaDB, MSSQL nebo SQLite. Privátní endpointy ponechte na interním DNS, povolte pouze potřebná odchozí volání a Wiki.js přidělte omezené oprávnění service accountu.

Topologii ověřte tak, že čistý klient dokončí nastavení, vytvoří a upraví stránku, nahraje média, vyhledá je a po restartu zkontroluje historii verzí. Během testu sledujte dobu odezvy databáze, indexování vyhledávání, úložiště médií a latenci poskytovatele autentizace. Výsledek ukáže, zda další zlepšení patří do oblasti paměti, úložiště, sítě nebo samostatného workeru, místo abyste náhodně upravovali velikost kontejneru.

Navrhněte obnovu Wiki.js ještě před spuštěním

Ve standardním image Wiki.js se neočekává žádný zapisovatelný stav aplikace. Uchovávejte databázi a případné lokální uploady i vlastní assety, včetně připnutého digestu a zkontrolované konfigurace routingu, místo zálohování prázdného filesystemu kontejneru.

Vytvořte Wiki.js od nuly na jiném hostiteli a ověřte, že se vrátí stránky, historie, uživatelé, skupiny, média i navigace a že známá stránka zůstane vyhledatelná. Pokud přidáte samostatnou databázi, room server nebo autentizační vrstvu, přidělte této komponentě vlastního, explicitně určeného vlastníka obnovy. Průvodce od Gitu do produkce ukazuje, jak reprodukovatelný artefakt nahrazuje zálohu kontejneru.

Příkaz pro obnovu a test s očekávaným výstupem evidujte spolu s releasem. Stateless plán obnovy uspěje reprodukcí chování z důvěryhodných vstupů; neměl by záviset na kopírování neprůhledného běžícího kontejneru.

Zvolte hranici důvěry Wiki.js

Bezpečné nasazení Wiki.js začíná odebráním oprávnění. Po vytvoření prvního administrátora nenechávejte obrazovku nastavení veřejně přístupnou; místo toho odeberte veřejný přístup k nastavení, omezte administraci a databázi wiki přidělte vlastní přihlašovací údaje.

S DB_PASS zacházejte podle jeho role ve Wiki.js: citlivé hodnoty držte mimo Git, zdokumentujte dopady rotace a v produkci nikdy nenahrazujte veřejný příklad skutečnou hodnotou. Omezte administrativní routy, pro závislosti používejte privátní DNS a zkontrolujte každý bind mount. Pokud se logy odesílají centrálně, před opuštěním serveru z nich odfiltrujte tajné údaje a soukromý obsah.

Co musí projít, než dorazí skutečná data Wiki.js

Produkční gate pro Wiki.js by měl dokázat provést někdo, kdo nasazení nevytvářel. Předejte této osobě připnutou verzi, testovací účet bez citlivých oprávnění a tento úkol: dokončit nastavení, vytvořit a upravit stránku, nahrát média, vyhledat je a po restartu zkontrolovat historii verzí. Pokud pokyny vyžadují nezdokumentovaný přístup přes shell, služba ještě není provozně připravená.

Gate zopakujte po nahrazení pouze kontejneru. Poté obnovte databázi a případné lokální uploady i vlastní assety do prázdné infrastruktury a prokažte, že se vrátí stránky, historie, uživatelé, skupiny, média i navigace a že známá stránka zůstane vyhledatelná. Během obou úspěšných běhů měřte dobu odezvy databáze, indexování vyhledávání, úložiště médií a latenci poskytovatele autentizace; neočekávané rozdíly často odhalí chybějící cache, index, worker nebo mount s daty.

Přidejte také nácvik selhání: dočasně testovací identitě odepřete přístup k dostupné databázi Postgres, MySQL, MariaDB, MSSQL nebo SQLite. Wiki.js by měl vypsat užitečnou chybu, zachovat stávající stav a po návratu platné podmínky se zotavit. Uložte časová razítka a relevantní řádky logu, přičemž tajné údaje začerňte. Tyto důkazy se stanou referencí pro další změnu image nebo konfigurace.

Spusťte Wiki.js, aniž byste skryli důležité části

Počáteční spuštění Wiki.js udržujte dostatečně reprodukovatelné, aby je bylo možné zkontrolovat v pull requestu.

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 příchodu skutečných dat nespoléhejte na latest. Uložte použitý digest, uživatele kontejneru a vlastnictví mountů. Sledujte log aplikace během celého testu — dokončete nastavení, vytvořte a upravte stránku, nahrajte média, vyhledejte je a po restartu zkontrolujte historii verzí — a před vystavením route produkčnímu provozu zaznamenejte případné migrace.

Udržujte interní a externí URL oddělené

S externí URL Wiki.js zacházejte jako s konfigurací, která musí přežít redeploy. Nejprve po směrování služby přes HTTPS nastavte URL webu; poté nasměrujte hostname na port 3000 se zachováním původního hostitele a schématu.

Checklist dostupnosti nasazení může prokázat, že požadavky vstupují do kontejneru. Poté je třeba známý problém — DB_HOST je uvnitř kontejneru nastavený na localhost nebo chybí hlavičky TLS proxy — hledat ve Wiki.js, jeho stavu nebo workloadu, nikoli v automatizaci certifikátů.

Sledujte workload, ne pouze kontejner

Postavte dashboardy kolem doby odezvy databáze, indexování vyhledávání, úložiště médií a latence poskytovatele autentizace. Graf CPU bez kontextu tohoto workloadu nedokáže vysvětlit, proč je Wiki.js pomalá. Přidejte syntetickou nebo plánovanou kontrolu, která s použitím neškodných testovacích dat zkusí dokončit nastavení, vytvořit a upravit stránku, nahrát média, vyhledat je a po restartu zkontrolovat historii verzí.

Před upgradem zohledněte toto specifické riziko aplikace: databázové migrace Wiki.js a autentizační moduly by měly být před přechodem na jinou release řadu otestovány ve stagingu. Obnovte aktuální zálohu do izolovaného nasazení, spusťte v něm migrace a porovnejte chování. Pokud je DB_HOST uvnitř kontejneru nastavený na localhost nebo chybí hlavičky TLS proxy, prozkoumejte příslušnou hranici — veřejný origin, úložiště nebo závislost — a teprve potom upravujte nesouvisející nastavení.

Udržujte Wiki.js explicitní, zatímco Dockup řeší routing

Routing, certifikáty, výměna služby a připojené úložiště jsou rozumné cíle pro automatizaci. Dockup je pro Wiki.js řeší a může také zprovisionovat související spravovanou databázi nebo se připojit ke službám na vlastním serveru zákazníka.

Neměl by však vymýšlet zásady důvěry Wiki.js. Po nasazení po směrování služby přes HTTPS nastavte URL webu, vynucujte tuto hranici — odeberte veřejný přístup k nastavení, omezte administraci a databázi wiki přidělte vlastní přihlašovací údaje — a ověřte výsledek tohoto scénáře: dokončit nastavení, vytvořit a upravit stránku, nahrát média, vyhledat je a po restartu zkontrolovat historii verzí. Výsledkem je infrastruktura na jedno kliknutí s akceptačním testem specifickým pro aplikaci.

Často kladené otázky

Co Wiki.js potřebuje pro produkční nasazení?

Kontejner Wiki.js směrujte na portu 3000 přes jeden HTTPS origin. Síťovým požadavkem je dostupná databáze Postgres, MySQL, MariaDB, MSSQL nebo SQLite. Wiki.js nepovažujte za připravenou, dokud nedokážete dokončit nastavení, vytvořit a upravit stránku, nahrát média, vyhledat je a po restartu zkontrolovat historii verzí.

Která data Wiki.js patří do zálohy?

Standardní image Wiki.js nemá žádný povinný mount s aplikačními daty. Uchovávejte její konfiguraci nasazení a každý připojený stav zálohujte samostatně; obnova je úspěšná, když se vrátí stránky, historie, uživatelé, skupiny, média i navigace a známá stránka zůstane vyhledatelná.

Vyžaduje Wiki.js za reverse proxy HTTPS?

Pro veřejný origin Wiki.js používejte HTTPS a port 3000 ponechte na interní route. Nastavení Wiki.js aplikujte správně: po směrování služby přes HTTPS nastavte URL webu. V případě Wiki.js HTTPS chrání přihlašovací údaje nebo obsah uživatelů při přenosu a zajišťuje konzistentní chování klienta citlivé na origin.

Jak testovat upgrade Wiki.js?

Obnovte aktuální stav Wiki.js do izolovaného nasazení, aplikujte kandidátní verzi a zopakujte akceptační transakci. Věnujte tomu zvláštní pozornost, protože databázové migrace Wiki.js a autentizační moduly by měly být před přechodem na jinou release řadu otestovány ve stagingu. Předchozí image Wiki.js si ponechte, dokud nebudete rozumět hranici migrace dat a rollbacku.