Jak samodzielnie hostować DokuWiki w 2026 roku: przechowywanie plików, ACL i kopie zapasowe

Traktuj DokuWiki jak mały system, a nie jak obraz Dockera. Cel z perspektywy użytkownika jest jasny: wiki oparte na plikach, które nie wymaga bazy danych; wdrożenie można uznać za akceptowalne dopiero wtedy, gdy można zmienić dane logowania konfiguracyjnego, edytować stronę, przesłać multimedia, zastosować ACL, wyświetlić rewizję i przywrócić starszą wersję.

To rozróżnienie pozwala wykryć problem, z którym operatorzy spotykają się po testach lokalnych: własność plików uniemożliwia zapisywanie stron, mimo że interfejs się ładuje. Umożliwia też przygotowanie planu tworzenia kopii zapasowych i aktualizacji na tyle konkretnego, by można go było przetestować.

Porty, procesy i usługi prywatne

Zacznij od przestrzeni nazw sieci DokuWiki: jego listener webowy działa na porcie 80, a nie na porcie hosta skopiowanym z laptopowego poradnika. Lokalne wymaganie środowiska uruchomieniowego to trwały wolumin konfiguracyjny zawierający strony, multimedia i ACL. Udokumentuj oczekiwaną pojemność, własność plików i scenariusz awarii, zamiast pozostawiać te kwestie jako domyślne ustawienia obrazu.

Po spełnieniu wymagania uruchom cały scenariusz — zmień dane logowania konfiguracyjnego, edytuj stronę, prześlij multimedia, zastosuj ACL, wyświetl rewizję i przywróć starszą wersję. Zapisz logi i pomiary dotyczące metadanych systemu plików, woluminu multimediów, indeksowania wyszukiwania i workerów PHP. Te dane staną się pierwszą znaną, poprawnie działającą architekturą i umożliwią testowanie późniejszych migracji między zasobami obliczeniowymi Dockup a dołączonym serwerem.

Testy awarii dla DokuWiki

Sprawny kontener jest niezbędny, ale niewystarczający. Wskaźnikiem na poziomie usługi jest pomyślne ukończenie scenariusza „zmień dane logowania konfiguracyjnego, edytuj stronę, prześlij multimedia, zastosuj ACL, wyświetl rewizję i przywróć starszą wersję”, natomiast prawdopodobne sygnały przeciążenia to metadane systemu plików, wolumin multimediów, indeksowanie wyszukiwania i workery PHP.

Kontrola zmian ma znaczenie, ponieważ wtyczki i szablony mogą nie nadążać za wydaniami DokuWiki, mimo że zwykłe pliki stron pozostają czytelne. Zachowaj stary obraz, testuj migracje na skopiowanym stanie i udokumentuj, czy po zmianie schematu możliwy jest rollback. Jeśli własność plików uniemożliwia zapisywanie stron, mimo że interfejs się ładuje, zdiagnozuj pierwszą granicę, która różni się od działającego środowiska.

Udokumentuj znane, poprawnie działające wdrożenie DokuWiki

Kandydat do wydania DokuWiki zasługuje na obsługę ruchu dopiero po pomyślnym wykonaniu ustalonego scenariusza: zmień dane logowania konfiguracyjnego, edytuj stronę, prześlij multimedia, zastosuj ACL, wyświetl rewizję i przywróć starszą wersję. Zapisz digest obrazu, efektywną konfigurację niezawierającą sekretów, publiczny origin oraz znaczniki czasu dla tego scenariusza. Dane testowe powinny nadawać się do usunięcia, ale być wystarczająco realistyczne, aby sprawdzać tę samą ścieżkę co użytkownicy.

Uruchom ten test po wymianie środowiska uruchomieniowego, a następnie odbuduj usługę na podstawie stron, multimediów, metadanych, użytkowników, ACL i wtyczek. Odzyskiwanie jest pomyślne, gdy wracają strony, rewizje, multimedia, użytkownicy, ACL i wtyczki, a chroniona strona nadal pozostaje chroniona. Porównaj pomiary zasobów dotyczące metadanych systemu plików, woluminu multimediów, indeksowania wyszukiwania i workerów PHP z poprzednim wydaniem, a przed wdrożeniem zbadaj istotne odchylenia.

Na koniec wykonaj kontrolowaną awarię: prześlij nieszkodliwe dane wejściowe w pobliżu limitu zasobów lub formatu związanego z tą granicą: własność plików uniemożliwia zapisywanie stron, mimo że interfejs się ładuje. Sprawdź, czy DokuWiki wyjaśnia awarię, nie uszkadza istniejącego stanu i wznawia działanie po przywróceniu prawidłowych warunków. Zapisz zanonimizowany fragment logu i czas odzyskiwania. Łącznie testy te obejmują działanie, trwałość i operacyjność, a nie tylko dostępność procesu.

Uruchom pierwszą instancję przypominającą środowisko produkcyjne

Użyj polecenia, które ujawnia każdą istotną decyzję. Ta konfiguracja bazowa wiąże DokuWiki z loopbackiem hosta, dodaje znane mounty danych i dostarcza pierwsze wymagane ustawienie. Przed udostępnieniem usługi potwierdź lokalne wymaganie: trwały wolumin konfiguracyjny zawierający strony, multimedia i ACL.

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

Zastąp pływające tagi przetestowaną wersją lub digestem. Po uruchomieniu sprawdź docker logs --tail 200 dokuwiki i potwierdź, że proces nasłuchuje na porcie 80. Następnie wykonaj działanie akceptacyjne DokuWiki; odpowiedź strony głównej nie dowodzi, że cały scenariusz działa: zmiana danych logowania konfiguracyjnego, edycja strony, przesłanie multimediów, zastosowanie ACL, wyświetlenie rewizji i przywrócenie starszej wersji.

Woluminy to dopiero pierwsza warstwa odzyskiwania

W przypadku DokuWiki bezpieczeństwo ponownego wdrożenia zaczyna się od stron, multimediów, metadanych, użytkowników, ACL i wtyczek. Zamontuj /config przed bootstrapem, zapisz nieszkodliwe przykładowe dane i wymień kontener, aby potwierdzić, że ta ścieżka rzeczywiście jest trwała. Przetestuj ją, wymieniając kontener, gdy przykładowe dane nadal istnieją; ujawni to mounty wskazujące o jeden katalog za wysoko lub za nisko.

Następnie przetestuj odzyskiwanie po awarii na pustym hoście. Tam, gdzie jest to konieczne, użyj spójnego z aplikacją eksportu bazy danych i sprawdź, czy wracają strony, rewizje, multimedia, użytkownicy, ACL i wtyczki, a chroniona strona nadal pozostaje chroniona. Poradnik dotyczący kopii zapasowych baz danych przetestowanych przez przywracanie wyznacza lepszy cel niż samo sprawdzenie, czy utworzono plik archiwum.

Nadaj DokuWiki jeden kanoniczny adres

Wydanie certyfikatu TLS to tylko połowa ścieżki DokuWiki. Udostępniaj wiki przez HTTPS i ustaw jej kanoniczny bazowy URL. Przekazuj ruch wewnętrznie na port 80 i przekazuj zewnętrzny schemat, aby generowane adresy URL i bezpieczne cookies pozostały spójne.

Wykonaj kompletny scenariusz DokuWiki z czystej sieci, a nie tylko dla strony głównej. Błąd 502 lub problem z certyfikatem można odizolować za pomocą automatycznej konfiguracji domeny i TLS. Jeśli ruch dociera do procesu, a własność plików uniemożliwia zapisywanie stron, mimo że interfejs się ładuje, zdiagnozuj ten warunek w miejscu jego wystąpienia, zamiast dokładać kolejne przekierowania.

Zamknij tymczasowy dostęp konfiguracyjny

Analizuj zagrożenia związane z działaniem wykonywanym przez DokuWiki, a nie tylko z formularzem logowania. W tym przypadku najpoważniejszym błędem jest pozostawienie otwartego instalatora lub ustawień rejestracji. Wprowadź tę granicę: usuń dostęp do instalatora, przejrzyj ustawienia rejestracji i zachowaj pliki ACL razem z zawartością stron.

DokuWiki nie wymaga w tej konfiguracji bazowej obowiązkowego sekretu bootstrapu; chroń rzeczywiste konto administratora lub użyj uwierzytelniania upstream. Nie rozwiązuj błędu uprawnień, uruchamiając kontener jako root ani montując szeroko system plików hosta. Limity zasobów również należą do projektu bezpieczeństwa, gdy użytkownicy mogą powodować wzrost liczby metadanych systemu plików, obciążenia woluminu multimediów, indeksowania wyszukiwania i workerów PHP.

Użyj Dockup jako warstwy platformy

Szablon Dockup powinien kodować obraz, port 80, mounty, czasy sprawdzania stanu, domenę, TLS i dostarczanie sekretów. Dockup powinien zachować ustawienia środowiska uruchomieniowego DokuWiki, podczas gdy operator potwierdza lokalne wymaganie: trwały wolumin konfiguracyjny zawierający strony, multimedia i ACL. To samo wdrożenie może być kierowane na serwery Dockup lub pojemność dołączoną przez klienta.

Po uruchomieniu ścieżki zastosuj ustawienie publiczne i spróbuj zmienić dane logowania konfiguracyjnego, edytować stronę, przesłać multimedia, zastosować ACL, wyświetlić rewizję i przywrócić starszą wersję. Wykonuj kopie zapasowe stron, multimediów, metadanych, użytkowników, ACL i wtyczek oraz zachowaj ćwiczenie przywracania w planie operacyjnym; są to obowiązki DokuWiki, które pozostają widoczne po aprowizacji infrastruktury.

Najczęściej zadawane pytania

Czego DokuWiki potrzebuje do wdrożenia produkcyjnego?

Skieruj kontener DokuWiki działający na porcie 80 przez jeden origin HTTPS. Lokalne wymaganie środowiska uruchomieniowego to trwały wolumin konfiguracyjny zawierający strony, multimedia i ACL. Nie uznawaj DokuWiki za gotowe, dopóki nie możesz zmienić danych logowania konfiguracyjnego, edytować strony, przesłać multimediów, zastosować ACL, wyświetlić rewizji i przywrócić starszej wersji.

Jakie dane DokuWiki powinny znaleźć się w kopii zapasowej?

Utrwal /config i uwzględnij strony, multimedia, metadane, użytkowników, ACL i wtyczki w tym samym manifeście odzyskiwania. Czyste przywrócenie DokuWiki kończy się powodzeniem tylko wtedy, gdy wracają strony, rewizje, multimedia, użytkownicy, ACL i wtyczki, a chroniona strona nadal pozostaje chroniona.

Czy DokuWiki wymaga HTTPS za reverse proxy?

Używaj HTTPS dla publicznego originu DokuWiki i pozostaw port 80 na trasie wewnętrznej. Zastosuj prawidłowe ustawienie DokuWiki: udostępniaj wiki przez HTTPS i ustaw jej kanoniczny bazowy URL. W przypadku DokuWiki HTTPS chroni dane logowania lub treści użytkowników podczas transmisji i zapewnia spójność zachowania klienta zależnego od originu.

Jak testować aktualizację DokuWiki?

Przywróć aktualny stan DokuWiki do odizolowanego wdrożenia, zastosuj wersję kandydującą i powtórz transakcję akceptacyjną. Zwróć szczególną uwagę na to, że wtyczki i szablony mogą nie nadążać za wydaniami DokuWiki, mimo że zwykłe pliki stron pozostają czytelne. Zachowaj poprzedni obraz DokuWiki do czasu zrozumienia granic migracji danych i rollbacku.