Jak hostować Wiki.js samodzielnie w 2026 roku: konfiguracja bazy danych, TLS i testy odtwarzania

Większość instrukcji instalacji Wiki.js kończy się na pierwszym wyświetleniu strony. To zbyt wcześnie: DB_HOST wskazuje localhost wewnątrz kontenera albo brakuje nagłówków proxy TLS. Przydatny test produkcyjny jest bardziej wymagający — ukończ konfigurację, utwórz i zmodyfikuj stronę, prześlij multimedia, wyszukaj je i po restarcie sprawdź historię wersji.

Rola Wiki.js jest prosta: to wiki w Markdownie z wersjonowaniem i nowoczesnym edytorem. Jego granice operacyjne obejmują więcej niż sam proces webowy, dlatego przed pojawieniem się rzeczywistych danych trzeba jasno określić zależność, przechowywany stan i publiczną trasę.

Określ granice środowiska uruchomieniowego Wiki.js

Najmniejsza odpowiedzialna topologia Wiki.js obejmuje jeden prywatny listener na porcie 3000, trasę ingress i udokumentowaną granicę stanu. Kontrakt sieciowy Wiki.js wymaga osiągalnej bazy Postgres, MySQL, MariaDB, MSSQL lub SQLite. Prywatne endpointy trzymaj w wewnętrznym DNS, zezwalaj tylko na wymagane połączenia wychodzące i nadaj Wiki.js ograniczone uprawnienia service account.

Zweryfikuj topologię, prosząc czystego klienta o ukończenie konfiguracji, utworzenie i modyfikację strony, przesłanie multimediów, wyszukanie ich oraz sprawdzenie historii wersji po restarcie. W trakcie działania obserwuj czas odpowiedzi bazy danych, indeksowanie wyszukiwania, storage multimediów i opóźnienia dostawcy uwierzytelniania. Wynik pokaże, czy kolejne usprawnienie powinno dotyczyć pamięci, storage, sieci czy osobnego workera, zamiast zachęcać do arbitralnego zwiększania zasobów kontenera.

Zaprojektuj odtwarzanie Wiki.js przed uruchomieniem

Standardowy obraz Wiki.js nie zakłada zapisywalnego stanu aplikacji wewnątrz obrazu. Zachowaj bazę danych oraz lokalne uploady i niestandardowe assety, w tym przypięty digest i przejrzaną konfigurację trasy, zamiast wykonywać backup pustego systemu plików kontenera.

Utwórz Wiki.js od zera na innym hoście i sprawdź, czy wracają strony, historia, użytkownicy, grupy, multimedia i nawigacja oraz czy znana strona pozostaje dostępna w wyszukiwarce. Jeśli dodana zostanie osobna baza danych, room server lub warstwa uwierzytelniania, przypisz temu komponentowi własnego, jasno określonego właściciela procesu odtwarzania. Poradnik od repozytorium Git do produkcji pokazuje, jak reprodukowalny artefakt zastępuje backup kontenera.

Zapisz polecenie odbudowy i test z oczekiwanym wynikiem razem z release'em. Bezstanowy plan odtwarzania działa dzięki odtworzeniu zachowania z zaufanych danych wejściowych; nie powinien zależeć od kopiowania nieprzejrzystego, działającego kontenera.

Wybierz granicę zaufania Wiki.js

Bezpieczne wdrożenie Wiki.js zaczyna się od odebrania uprawnień. Po utworzeniu pierwszego administratora nie pozostawiaj publicznie dostępnego ekranu konfiguracji; zamiast tego usuń publiczny dostęp do konfiguracji, ogranicz administrację i nadaj bazie wiki własne dane uwierzytelniające.

Traktuj DB_PASS zgodnie z jego rolą w Wiki.js: trzymaj poufne wartości poza Gitem, dokumentuj skutki rotacji i nigdy nie zastępuj publicznego przykładu wartością używaną na produkcji. Ogranicz trasy administracyjne, używaj prywatnego DNS dla zależności i sprawdzaj każde bind mount. Gdy logi są wysyłane centralnie, filtruj sekrety i prywatne treści, zanim opuszczą serwer.

Co musi przejść, zanim pojawią się rzeczywiste dane Wiki.js

Bramka produkcyjna dla Wiki.js powinna być możliwa do wykonania przez osobę, która nie wdrażała systemu. Przekaż jej przypiętą wersję, konto testowe bez poufnych danych i następujące zadanie: ukończyć konfigurację, utworzyć i zmodyfikować stronę, przesłać multimedia, wyszukać je i po restarcie sprawdzić historię wersji. Jeśli instrukcja wymaga nieudokumentowanego dostępu przez shell, usługa nie jest jeszcze gotowa operacyjnie.

Powtórz bramkę po wymianie wyłącznie kontenera. Następnie odtwórz bazę danych oraz lokalne uploady i niestandardowe assety w pustej infrastrukturze i udowodnij, że wracają strony, historia, użytkownicy, grupy, multimedia i nawigacja oraz że znana strona pozostaje dostępna w wyszukiwarce. Podczas obu pomyślnych uruchomień mierz czas odpowiedzi bazy danych, indeksowanie wyszukiwania, storage multimediów i opóźnienia dostawcy uwierzytelniania; nieoczekiwane różnice często ujawniają brak cache, indeksu, workera lub mountu danych.

Dodaj ćwiczenie awaryjne: tymczasowo odbierz testowej tożsamości dostęp do osiągalnej bazy Postgres, MySQL, MariaDB, MSSQL lub SQLite. Wiki.js powinien zwrócić użyteczny błąd, zachować istniejący stan i odzyskać działanie po przywróceniu prawidłowych warunków. Zapisz znaczniki czasu i odpowiednie fragmenty logów, usuwając sekrety. Te dowody staną się punktem odniesienia dla kolejnego obrazu lub zmiany konfiguracji.

Uruchom Wiki.js bez ukrywania elementów środowiska

Początkowe wywołanie Wiki.js powinno być na tyle reprodukowalne, aby można je było przejrzeć w pull requeście.

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 pojawieniu się rzeczywistych danych nie polegaj na latest. Zapisz działający digest, użytkownika kontenera i właściciela mountów. Śledź log aplikacji przez cały test — ukończ konfigurację, utwórz i zmodyfikuj stronę, prześlij multimedia, wyszukaj je i po restarcie sprawdź historię wersji — oraz odnotuj ewentualne migracje przed skierowaniem trasy do ruchu produkcyjnego.

Rozdziel adresy wewnętrzne i zewnętrzne

Traktuj zewnętrzny adres URL Wiki.js jako konfigurację, która przetrwa redeploye. Najpierw skonfiguruj adres URL witryny po skierowaniu usługi przez HTTPS, a następnie skieruj hostname na port 3000, zachowując oryginalny host i schemat.

Lista kontrolna osiągalności wdrożenia pozwala potwierdzić, że żądania trafiają do kontenera. Później znanego problemu — DB_HOST wskazuje localhost wewnątrz kontenera albo brakuje nagłówków proxy TLS — należy szukać w Wiki.js, jego stanie lub workloadzie, a nie w automatyzacji certyfikatów.

Obserwuj workload, nie tylko kontener

Zbuduj dashboardy wokół czasu odpowiedzi bazy danych, indeksowania wyszukiwania, storage multimediów i opóźnień dostawcy uwierzytelniania. Wykres CPU bez kontekstu workloadu nie wyjaśni, dlaczego Wiki.js działa wolno. Dodaj syntetyczny lub cykliczny check, który przy użyciu nieszkodliwych danych testowych próbuje ukończyć konfigurację, utworzyć i zmodyfikować stronę, przesłać multimedia, wyszukać je oraz po restarcie sprawdzić historię wersji.

Przed aktualizacją uwzględnij zagrożenie charakterystyczne dla tej aplikacji: migracje bazy danych Wiki.js i moduły uwierzytelniania powinny zostać przygotowane przed przejściem na inną linię wydań. Odtwórz niedawny backup w odizolowanym wdrożeniu, uruchom tam migracje i porównaj działanie. Jeśli DB_HOST wskazuje localhost wewnątrz kontenera albo brakuje nagłówków proxy TLS, najpierw sprawdź odpowiednią granicę — publiczne źródło, storage lub zależność — zanim zmienisz niezwiązane ustawienia.

Zachowaj jawność Wiki.js, a routing powierz Dockup

Routing, certyfikaty, wymiana usług i podłączony storage to rozsądne cele automatyzacji. Dockup obsługuje je dla Wiki.js, a także może provisionować powiązaną zarządzaną bazę danych lub łączyć się z usługami na własnym serwerze klienta.

Nie powinien jednak wymyślać polityki zaufania Wiki.js. Po wdrożeniu skonfiguruj adres URL witryny po skierowaniu usługi przez HTTPS, wyegzekwuj tę granicę — usuń publiczny dostęp do konfiguracji, ogranicz administrację i nadaj bazie wiki własne dane uwierzytelniające — oraz zweryfikuj następujący scenariusz: ukończ konfigurację, utwórz i zmodyfikuj stronę, prześlij multimedia, wyszukaj je i po restarcie sprawdź historię wersji. Rezultatem jest infrastruktura wdrażana jednym kliknięciem wraz z aplikacyjnym testem akceptacyjnym.

Często zadawane pytania

Czego Wiki.js potrzebuje do wdrożenia produkcyjnego?

Skieruj kontener Wiki.js na porcie 3000 przez jeden origin HTTPS. Wymaganiem sieciowym jest osiągalna baza Postgres, MySQL, MariaDB, MSSQL lub SQLite. Nie uznawaj Wiki.js za gotowe, dopóki nie możesz ukończyć konfiguracji, utworzyć i zmodyfikować strony, przesłać multimediów, wyszukać ich oraz po restarcie sprawdzić historii wersji.

Które dane Wiki.js powinny znaleźć się w backupie?

Standardowy obraz Wiki.js nie ma wymaganego mountu z danymi aplikacji. Zachowaj konfigurację wdrożenia i wykonuj backup każdego podłączonego stanu osobno; odtwarzanie kończy się powodzeniem, gdy wracają strony, historia, użytkownicy, grupy, multimedia i nawigacja oraz gdy znana strona pozostaje dostępna w wyszukiwarce.

Czy Wiki.js wymaga HTTPS za reverse proxy?

Używaj HTTPS dla publicznego originu Wiki.js, a port 3000 pozostaw na trasie wewnętrznej. Zastosuj prawidłowo ustawienie Wiki.js: skonfiguruj adres URL witryny po skierowaniu usługi przez HTTPS. W przypadku Wiki.js HTTPS chroni dane uwierzytelniające i treści użytkowników podczas transmisji oraz zapewnia spójne działanie klienta zależne od originu.

Jak testować aktualizację Wiki.js?

Odtwórz bieżący stan Wiki.js w odizolowanym wdrożeniu, zastosuj wersję kandydującą i powtórz transakcję akceptacyjną. Zwróć szczególną uwagę na to, że migracje bazy danych Wiki.js i moduły uwierzytelniania powinny zostać przygotowane przed przejściem na inną linię wydań. Zachowaj poprzedni obraz Wiki.js, dopóki granice migracji danych i rollbacku nie będą zrozumiałe.