Rozwiązanie społecznościowe

AdventureLog w ZimaOS: rozwiązywanie problemów z rejestracją, PostgreSQL, adresem URL interfejsu i plikiem Compose

A June 2025 ZimaOS custom-app thread where AdventureLog opened but signup did nothing. Logs later showed repeated frontend fetch timeouts and a backend waiting for PostgreSQL. The thread never posted a confirmed working fix. AdventureLog's current upstream Compose has since changed substantially.

Wątek źródłowy z 2025 roku nie doprowadził do potwierdzonej, działającej instalacji AdventureLog. Frontend się ładował, ale rejestracja wyglądała na nieaktywną. Późniejsze dzienniki ujawniły dwie silniejsze wskazówki: frontend wielokrotnie zgłaszał fetch failed z przekroczeniami limitu czasu połączenia, podczas gdy backend wielokrotnie zgłaszał PostgreSQL jest niedostępny — oczekiwanie. Sam kontener bazy danych ostatecznie zakończył inicjalizację i zaczął normalnie nasłuchiwać.

Dowody te wskazują na problem z łącznością/konfiguracją wielu usług, a nie na prosty wniosek, że „AdventureLog nie działa na ZimaOS”. Aktualne wdrożenie upstream AdventureLog również się zmieniło: obecnie utrzymywany plik Compose używa .env plik, nowszy PostGIS, aktualne obrazy frontendu i backendu oraz dedykowany instalator, który pyta o zewnętrzne adresy URL frontendu i backendu.

Źródło używało stosu Compose złożonego z trzech usług

Plik Compose z 2025 roku zawierał:

  • frontend SvelteKit o nazwie web;
  • usługę Django/backend o nazwie server;
  • bazę danych PostGIS/PostgreSQL o nazwie db.

Frontend udostępniał port hosta 8015, backend udostępniał inny port hosta, a nazwane wolumeny Dockera przechowywały dane bazy danych i multimediów.

Widocznym objawem był ekran rejestracji, który nie reagował

Aplikacja wyglądała na pomyślnie zainstalowaną z poziomu ZimaOS Custom App, ale użytkownik nie mógł przejść przez logowanie/rejestrację. Taki objaw po stronie frontendu może być spowodowany przez:

  • frontendowi nieudaje się połączyć z backendem;
  • backendowi nieudaje się połączyć z PostgreSQL;
  • nieprawidłowe adresy URL origin/CSRF;
  • kolejność uruchamiania usług lub ich stan gotowości;
  • proxy odwrotny zmieniający efektywny zewnętrzny adres URL.

Dzienniki źródłowe zawierały dowody dotyczące dwóch pierwszych warstw, ale nie wskazywały jednoznacznie ostatecznej przyczyny problemu.

Frontend wielokrotnie przekraczał limit czasu podczas pobierania danych

Dziennik frontendu zgłaszał TypeError: fetch failed oraz ETIMEDOUT. Oznacza to, że proces frontendu nie mógł ukończyć żądania sieciowego, które powinno było zakończyć się powodzeniem.

Oryginalny plik Compose używał PUBLIC_SERVER_URL=http://server:8000, co jest koncepcyjnie poprawne w przypadku komunikacji między usługami w ramach jednego projektu Compose. Jednak zmiana innych zmiennych URL na adresy LAN lub domeny proxy może nadal powodować niezgodności między originem a przeglądarką i backendem.

Backend początkowo nie mógł połączyć się z PostgreSQL

Dziennik backendu wielokrotnie wyświetlał PostgreSQL jest niedostępny — oczekiwanie. Tymczasem dziennik bazy danych pokazywał inicjalizację PostGIS i ostateczne przejście w stan gotowości.

Jest to zgodne z sytuacją, w której backend uruchamia się przed gotowością bazy danych, ustawienie połączenia z bazą danych jest nieprawidłowe lub występuje problem z siecią usług. Źródło nie zawiera wystarczających dowodów, aby jednoznacznie rozróżnić te możliwości.

Dodanie tunelu Cloudflare nie naprawiło pierwotnego problemu

Użytkownik wypróbował tunel Cloudflare po pierwszej nieudanej instalacji, ale aplikacja nadal nie działała. Jest to oczekiwane, jeśli podstawowa ścieżka frontend ↔ backend ↔ baza danych jest uszkodzona: publiczny tunel może udostępnić usługę, ale nie naprawia wewnętrznej sieci Compose.

Aktualny AdventureLog korzysta z prostszego, utrzymywanego układu Compose

Aktualny plik Compose AdventureLog używany w projekcie nadrzędnym zawiera:

  • ghcr.io/seanmorley15/adventurelog-frontend:latest;
  • ghcr.io/seanmorley15/adventurelog-backend:latest;
  • postgis/postgis:16-3.5;
  • wspólny .env plik
  • trwałe postgres_data oraz adventurelog_media wolumeny.

Przejrzyj aktualną definicję Compose AdventureLog, zamiast kopiować plik YAML z forum z 2025 roku słowo w słowo.

Celowo skonfiguruj adresy URL frontendu i backendu

Aktualny instalator AdventureLog prosi o adres URL frontendu i adres URL backendu oraz wyprowadza z nich konfigurację portów. To silny sygnał, że wartości URL i origin są częścią kontraktu aplikacji, a nie jedynie etykietami bez znaczenia.

W przypadku konfiguracji wyłącznie w sieci LAN używaj rzeczywistego adresu IP lub nazwy hosta ZimaOS oraz wybranych portów w spójny sposób. W przypadku odwrotnego serwera proxy skonfiguruj publiczne adresy HTTPS w spójny sposób i unikaj mieszania localhost, adresów LAN i domen publicznych bez zrozumienia, który proces odczytuje każdą z tych wartości.

Nie zachowuj haseł źródłowych ani SECRET_KEY

Plik Compose z forum zawierał wartości zastępcze, takie jak changeme123 dla sekretów PostgreSQL i Django. To przykłady, a nie bezpieczne dane uwierzytelniające do produkcji.

Wygeneruj unikatowe dane logowania do bazy danych oraz silny sekret aplikacji. Jeśli prawdziwy sekret kiedykolwiek został opublikowany publicznie, zmień go.

Zachowaj bazę danych i multimedia przed rozpoczęciem diagnozowania ponownych instalacji

Wielokrotne odinstalowywanie i ponowne instalowanie stosu może powodować niejasny stan, jeśli nazwane wolumeny przetrwają lub zostaną nieoczekiwanie usunięte. Zdecyduj, czy celem jest:

  • użyj ponownie istniejącej bazy danych i multimediów;
  • rozpocznij od całkowicie czystej instancji testowej.

Przed usunięciem wolumenów Dockera wykonaj kopię zapasową wszystkiego, co ważne.

Aktualny ZimaOS obsługuje standardowy Compose bardziej bezpośrednio

Aktualny Sklep aplikacji ZimaOS 2.0 i przepływy pracy aplikacji niestandardowych opierają się na standardowym Docker Compose oraz metadanych ZimaOS. Zachowanie aplikacji w czasie działania — zależności, zmienne środowiskowe, porty, wolumeny, stan zdrowia i sieci — nadal należy definiować w Compose.

Podczas dostosowywania AdventureLog użyj aktualnego modelu Compose ZimaOS.

FAQ: AdventureLog w ZimaOS

Czy wątek źródłowy z 2025 roku potwierdził działającą poprawkę?

Nie. Wątek zakończył się po opublikowaniu przez użytkownika logów frontendu, backendu i bazy danych.

Jakie były najmocniejsze wskazówki w źródłach?

Limity czasu pobierania danych przez frontend oraz backend wielokrotnie oczekujący na PostgreSQL.

Czy stary plik Compose z 2025 roku należy ponownie wykorzystać bez zmian?

Nie. Zmieniono utrzymywaną konfigurację Compose, obrazy, wersję PostGIS i model konfiguracji AdventureLog.