AdventureLog på ZimaOS: Korrigeringar för Compose och PostgreSQL

Källtråden från 2025 nådde aldrig fram till en bekräftat fungerande AdventureLog-installation. Frontend laddades, men registreringen verkade inte göra någonting. Senare loggar visade två tydligare ledtrådar: frontend rapporterade upprepade gånger fetch failed med anslutningstimeoutar, medan backend upprepade gånger angav PostgreSQL är inte tillgängligt – väntar. Själva databaskcontainern initierades så småningom och började lyssna normalt.

Detta pekar på ett problem med anslutning eller konfiguration mellan flera tjänster snarare än slutsatsen att ”AdventureLog inte fungerar på ZimaOS”. AdventureLogs aktuella distribution uppströms har också ändrats: den underhållna Compose-konfigurationen använder nu en .env fil, nyare PostGIS, aktuella frontend-/backendavbildningar och ett dedikerat installationsprogram som frågar efter de externa frontend- och backend-URL:erna.

Källan använde en Compose-stack med tre tjänster

Compose-konfigurationen från 2025 innehöll:

en SvelteKit-frontend kallad web;
en Django-/backendtjänst kallad server;
en PostGIS-/PostgreSQL-databas kallad db.

Frontend exponerade värdport 8015, backend exponerade en annan värdport och namngivna Docker-volymer lagrade databas- och mediedata.

Applikationen verkade installeras korrekt från ZimaOS Custom App, men användaren kunde inte gå vidare genom inloggningen/registreringen. Ett sådant frontend-symptom kan orsakas av:

frontend kunde inte nå backend;
backend kunde inte nå PostgreSQL;
felaktiga origin-/CSRF-URL:er;
tjänstestartens ordning eller hälsostatus;
en reverse proxy som ändrar den effektiva externa URL:en.

Källoggarna innehöll belägg för de två första lagren, men fastställde inte en enda slutgiltig grundorsak.

Frontend fick upprepade tidsgränsöverskridanden vid hämtning

Frontendloggen rapporterade TypeError: fetch failed och ETIMEDOUT. Det innebar att frontendprocessen inte kunde slutföra en nätverksbegäran som den förväntade sig skulle lyckas.

Den ursprungliga Compose-konfigurationen använde PUBLIC_SERVER_URL=http://server:8000, vilket är konceptuellt korrekt för kommunikation mellan tjänster inom ett Compose-projekt. Att ändra andra URL-variabler till LAN-adresser eller proxydomäner kan dock fortfarande skapa avvikelser mellan origin och webbläsare/backend.

Backend kunde inledningsvis inte nå PostgreSQL

Backendloggen skrev upprepade gånger ut PostgreSQL är inte tillgängligt – väntar. Samtidigt visade databasloggen att PostGIS initierades och så småningom blev redo.

Detta stämmer överens med att backend startar innan databasen är redo, en felaktig DB-anslutningsinställning eller ett tjänstenätverksproblem. Källan innehåller inte tillräckligt med bevis för att slutgiltigt skilja mellan dessa möjligheter.

Att lägga till en Cloudflare Tunnel löste inte grundproblemet

Användaren försökte med en Cloudflare Tunnel efter den första misslyckade installationen, men applikationen fungerade fortfarande inte. Det är förväntat om den underliggande frontend ↔ backend ↔ databas-kommunikationen är trasig: en offentlig tunnel kan exponera en tjänst, men den reparerar inte intern Compose-nätverkstrafik.

Aktuella AdventureLog använder en enklare underhållen Compose-struktur

AdventureLogs aktuella Compose-konfiguration från upstream använder nu:

ghcr.io/seanmorley15/adventurelog-frontend:latest;
ghcr.io/seanmorley15/adventurelog-backend:latest;
postgis/postgis:16-3.5;
en gemensam .env fil för tjänstekonfiguration;
beständiga postgres_data och adventurelog_media volymer.

Granska den aktuella Compose-definitionen för AdventureLog i stället för att kopiera forumets YAML från 2025 ordagrant.

Konfigurera frontend- och backend-URL:er medvetet

Det aktuella installationsprogrammet för AdventureLog frågar efter frontend- och backend-URL:erna och härleder portkonfigurationen från dem. Det är en stark signal om att URL-/origin-värden ingår i programmets kontrakt och inte bara är kosmetiska etiketter.

För en LAN-baserad installation använder du ZimaOS faktiska IP-adress/värdnamn och de valda portarna konsekvent. För en omvänd proxy konfigurerar du de offentliga HTTPS-URL:erna konsekvent och undviker att blanda localhost, LAN-adresser och offentliga domäner utan att förstå vilken process som ser varje värde.

Använd inte källans lösenord och SECRET_KEY

Compose-konfigurationen från forumet innehöll platshållarvärden som changeme123 för PostgreSQL- och Django-hemligheter. Det är exempel, inte säkra produktionsuppgifter.

Skapa unika databasuppgifter och en stark programhemlighet. Om en riktig hemlighet någon gång har publicerats offentligt ska den roteras.

Behåll databas och mediefiler innan du felsöker ominstallationer

Om stacken avinstalleras och installeras om upprepade gånger kan det uppstå förvirrande tillstånd om namngivna volymer finns kvar eller tas bort oväntat. Bestäm om målet är att:

återanvänd den befintliga databasen/mediefilerna;
börja med en helt ren testinstans.

Säkerhetskopiera allt viktigt innan du tar bort Docker-volymer.

Aktuella ZimaOS hanterar standard-Compose mer direkt

Aktuella arbetsflöden för ZimaOS App Store 2.0 och anpassade appar bygger på standard-Docker Compose tillsammans med ZimaOS-metadata. Programmets körningsbeteende – beroenden, miljövariabler, portar, volymer, hälsokontroller och nätverk – hör fortfarande hemma i Compose.

Använd den aktuella Compose-modellen för ZimaOS när du anpassar AdventureLog.

Vanliga frågor om AdventureLog på ZimaOS

Bekräftade källtråden från 2025 en fungerande lösning?

Nej. Tråden avslutades efter att användaren publicerade loggar från frontend, backend och databasen.

Vilka var de starkaste ledtrådarna i källmaterialet?

Timeouts vid hämtning från frontend och en backend som upprepade gånger väntar på PostgreSQL.

Bör den gamla Compose-konfigurationen från 2025 återanvändas oförändrad?

Nej. AdventureLogs underhållna Compose-konfiguration, avbildningar, PostGIS-version och konfigurationsmodell har ändrats.