Jak hostować Shiori samodzielnie w 2026 roku: archiwa, konta i trwałe przechowywanie danych
Praktyczny poradnik self-hostingu Shiori obejmujący Docker, porty, trwałość danych, TLS, bezpieczeństwo, backupy oraz problemy blokujące użycie produkcyjne. Krok po kroku.
Nieudane wdrożenie Shiori nie zawsze kończy się awarią. Aplikacja może wyświetlać stronę logowania, podczas gdy archiwizacja nie działa z powodu nieprawidłowych zależności Chromium albo uprawnień systemu plików. Zamiast tego rozpocznij od kompleksowego testu: zapisz zakładkę z zarchiwizowaną treścią, wyszukaj ją, edytuj tagi i sprawdź, czy archiwum pozostaje dostępne po zmianie strony źródłowej.
Ten test odpowiada katalogowemu przeznaczeniu Shiori: jest to menedżer zakładek archiwizujący treść stron. Ujawnia też brakujące zależności, błędne założenia dotyczące proxy oraz ulotność danych wcześniej niż test uptime.
Wyznacz granicę środowiska uruchomieniowego Shiori
Stan procesu i stan produktu to w przypadku Shiori dwie różne rzeczy. Port 8080 może odpowiadać, mimo że transakcja z perspektywy użytkownika nadal kończy się niepowodzeniem. Zewnętrzne wymagania Shiori to zapisywalny data volume oraz dostęp wychodzący do archiwizowanych stron. Testuj zewnętrzny DNS, TLS i zachowanie dostawcy bez publikowania kolejnej usługi dostępnej z zewnątrz.
Wykonuj ten test gotowości po istotnych zmianach konfiguracji: zapisz zakładkę z zarchiwizowaną treścią, wyszukaj ją, edytuj tagi i sprawdź, czy archiwum pozostaje dostępne po zmianie strony źródłowej. Nie umieszczaj kosztownych testów zewnętrznych w liveness probes, aby awaria dostawcy nie powodowała pętli restartów. Prace nad wydajnością powinny uwzględniać przechwytywanie stron za pomocą przeglądarki, rozmiar archiwum, miniatury i pobieranie danych z zewnątrz — to lepiej odzwierciedla rzeczywiste obciążenie Shiori niż żądania stron.
Odtwórz Shiori na pustym hoście
Zanim utworzysz pierwszy rzeczywisty rekord, wyszczególnij wszystkie dane stanu: bazę danych, zarchiwizowaną treść stron, miniatury i konfigurację. Zamontuj /shiori przed bootstrapem, zapisz nieszkodliwe dane testowe i wymień kontener, aby potwierdzić, że ta ścieżka rzeczywiście jest trwała. Potwierdź mount, zapisując nieszkodliwe dane, wymieniając Shiori i odczytując je ponownie.
Snapshoty są przydatne do szybkiego rollbacku, ale gdy host lub volume zniknie, potrzebny jest niezależny backup. Odtwórz dane w pustym środowisku z przypiętym obrazem i sprawdź, czy wracają zakładki, tagi, pliki archiwów i konta oraz czy niedziałający link źródłowy nadal otwiera zapisany materiał. Użyj persistent volumes i snapshotów, aby zachować rozdział między tymi dwoma mechanizmami odtwarzania.
Decyzje dotyczące bezpieczeństwa specyficzne dla Shiori
Ryzykiem bezpieczeństwa specyficznym dla aplikacji jest pozostawienie niezmienionego początkowego konta na publicznej instancji. Właściwe postępowanie to zastąpienie początkowego konta, ograniczenie publicznego udostępniania oraz traktowanie prywatnych URL-i archiwów jako poufnych treści. Zakończ bootstrap przez ograniczoną trasę i natychmiast usuń tymczasowy dostęp konfiguracyjny.
SHIORI_DIR steruje działaniem, a nie poufnością. Zweryfikuj jego typ i wartość, a właściwe dane uwierzytelniające Shiori przechowuj oddzielnie. Przyznaj procesowi Shiori wyłącznie udokumentowane mounty i trasy zależności; unikaj dostępu do roota hosta i socketu Dockera. Rejestruj nieudane uwierzytelnienia i błędy konfiguracji, ale usuwaj z logów tokeny, connection stringi i treści użytkowników.
Test akceptacyjny Shiori przed wdrożeniem produkcyjnym
Kandydat do wydania Shiori zasługuje na obsługę ruchu dopiero po wykonaniu ustalonego scenariusza: zapisz zakładkę z zarchiwizowaną treścią, wyszukaj ją, edytuj tagi i sprawdź, czy archiwum pozostaje dostępne po zmianie strony źródłowej. Zapisz digest obrazu, efektywną konfigurację pozbawioną sekretów, publiczny origin i znaczniki czasu tego scenariusza. Dane testowe powinny nadawać się do usunięcia, ale być na tyle realistyczne, aby przejść tą samą ścieżką co użytkownicy.
Uruchom test po wymianie środowiska uruchomieniowego, a następnie odtwórz usługę z bazy danych, zarchiwizowanej treści stron, miniatur i konfiguracji. Odtwarzanie kończy się powodzeniem, gdy wracają zakładki, tagi, pliki archiwów i konta oraz gdy niedziałający link źródłowy nadal otwiera zapisany materiał. Porównaj pomiary zasobów dotyczące przechwytywania stron za pomocą przeglądarki, rozmiaru archiwum, miniatur i pobierania danych z zewnątrz z poprzednim wydaniem. Zbadaj istotne odchylenia przed wdrożeniem.
Na koniec przeprowadź kontrolowaną awarię: tymczasowo zablokuj ścieżkę testową używaną przez zapisywalny data volume oraz dostęp wychodzący do archiwizowanych stron. Sprawdź, czy Shiori wyjaśnia przyczynę awarii, nie uszkadza istniejącego stanu i wznawia działanie po przywróceniu prawidłowych warunków. Zapisz zanonimizowany fragment logu oraz czas przywrócenia działania. Łącznie testy te obejmują zachowanie, trwałość i operacyjność, a nie tylko uptime procesu.
Uruchom Shiori z obserwowalnymi ustawieniami domyślnymi
Zadbaj o to, aby początkowe uruchomienie Shiori było na tyle powtarzalne, by można je było zweryfikować w pull requeście.
docker run -d \
--name shiori \
--restart unless-stopped \
-p 127.0.0.1:8080:8080 \
-v shiori-data:/shiori \
-e SHIORI_DIR=/shiori \
ghcr.io/go-shiori/shiori:latest
Po zapisaniu rzeczywistych danych nie polegaj na latest. Zapisz działający digest, użytkownika kontenera i właściciela mountu. Śledź log aplikacji przez cały test — zapisz zakładkę z zarchiwizowaną treścią, wyszukaj ją, edytuj tagi i sprawdź, czy archiwum pozostaje dostępne po zmianie strony źródłowej — oraz odnotuj ewentualne migracje przed skierowaniem trasy do ruchu produkcyjnego.
Domeny, nagłówki proxy i port 8080
Traktuj zewnętrzny URL Shiori jako konfigurację, która musi przetrwać kolejne redeploye. Najpierw kieruj UI i API przez stabilny HTTPS origin, a następnie skieruj hostname na port 8080, zachowując oryginalny host i schemat.
Lista kontrolna dostępności wdrożenia może potwierdzić, że żądania docierają do kontenera. Od tego momentu znany problem — archiwizacja nie działa z powodu nieprawidłowych zależności Chromium albo uprawnień systemu plików — należy analizować w Shiori, jego stanie lub obciążeniu, a nie w automatyzacji certyfikatów.
Aktualizuj Shiori bez zgadywania
Pierwszą użyteczną metryką operacyjną dla Shiori jest możliwość zapisania zakładki z zarchiwizowaną treścią, wyszukania jej, edycji tagów i potwierdzenia, że archiwum pozostaje dostępne po zmianie strony źródłowej. Połącz ją z sygnałami przeciążenia dotyczącymi przechwytywania stron za pomocą przeglądarki, rozmiaru archiwum, miniatur i pobierania danych z zewnątrz. Probe sprawdzający wyłącznie stan procesu nie powinien wywoływać kosztownych zależności ani restartować kontenera z powodu chwilowej niedostępności upstreamu.
Traktuj aktualizacje jako zmiany danych, ponieważ migracje bazy danych Shiori i zależności związane z przechwytywaniem stron mogą zmienić działanie archiwum. Przypinaj wersje, przeprowadzaj próby na odtworzonym stanie i zachowaj poprzedni obraz, dopóki rollback pozostaje możliwy. Gdy archiwizacja nie działa z powodu nieprawidłowych zależności Chromium albo uprawnień systemu plików, zachowaj logi sprzed restartu — zwykle zawierają komunikat wskazujący przyczynę.
Co Dockup powinien automatyzować dla Shiori
Warstwa platformowa Shiori obejmuje port 8080, ingress, TLS, konfigurację środowiska uruchomieniowego, storage i dostępność zależności. Dockup może odtworzyć te elementy we własnej infrastrukturze lub na serwerze podłączonym przez klienta.
Następnie operator kończy konfigurację warstwy produktu: kieruje UI i API przez stabilny HTTPS origin; egzekwuje tę zasadę dostępu — zastępuje początkowe konto, ogranicza publiczne udostępnianie i traktuje prywatne URL-e archiwów jako poufne treści; oraz uruchamia test „zapisz zakładkę z zarchiwizowaną treścią, wyszukaj ją, edytuj tagi i sprawdź, czy archiwum pozostaje dostępne po zmianie strony źródłowej”. Zapisanie tego testu razem z wdrożeniem pozwala uniknąć mylenia automatycznego provisioningu z gotowością aplikacji.
Najczęściej zadawane pytania
Czego Shiori potrzebuje do wdrożenia produkcyjnego?
Skieruj kontener Shiori z portu 8080 przez jeden HTTPS origin. Zewnętrzne wymagania dotyczące dostarczania usługi to zapisywalny data volume oraz dostęp wychodzący do archiwizowanych stron. Nie uznawaj Shiori za gotowe, dopóki nie możesz zapisać zakładki z zarchiwizowaną treścią, wyszukać jej, edytować tagów i potwierdzić, że archiwum pozostaje dostępne po zmianie strony źródłowej.
Które dane Shiori należy uwzględnić w backupie?
Utrwal /shiori i uwzględnij bazę danych, zarchiwizowaną treść stron, miniatury oraz konfigurację w tym samym manifeście odtwarzania. Czyste odtworzenie Shiori kończy się powodzeniem tylko wtedy, gdy wracają zakładki, tagi, pliki archiwów i konta oraz gdy niedziałający link źródłowy nadal otwiera zapisany materiał.
Czy Shiori wymaga HTTPS za reverse proxy?
Używaj HTTPS dla publicznego originu Shiori, a port 8080 pozostaw na trasie wewnętrznej. Zastosuj poprawnie ustawienie Shiori: kieruj UI i API przez stabilny HTTPS origin. W przypadku Shiori HTTPS chroni dane uwierzytelniające lub treści użytkowników podczas przesyłania i zapewnia spójne działanie klienta zależne od originu.
Jak testować aktualizację Shiori?
Odtwórz bieżący stan Shiori w odizolowanym wdrożeniu, zastosuj wersję kandydującą i powtórz transakcję akceptacyjną. Zwróć szczególną uwagę na ten etap, ponieważ migracje bazy danych Shiori i zależności związane z przechwytywaniem stron mogą zmienić działanie archiwum. Zachowaj poprzedni obraz Shiori do czasu zrozumienia granic migracji danych i rollbacku.