La discussion source de 2025 n’a jamais abouti à une installation fonctionnelle confirmée d’AdventureLog. Le frontend se chargeait, mais l’inscription semblait ne rien faire. Les journaux ultérieurs ont révélé deux indices plus probants : le frontend signalait à plusieurs reprises : échec de la récupération avec des délais d’attente de connexion, tandis que le backend indiquait à plusieurs reprises PostgreSQL est indisponible – mise en veille. Le conteneur de base de données s’est finalement initialisé et a commencé à écouter normalement.
Ces éléments indiquent un problème de connectivité ou de configuration entre plusieurs services, plutôt qu’une simple conclusion selon laquelle « AdventureLog ne fonctionne pas sur ZimaOS ». Le déploiement amont actuel d’AdventureLog a également changé : son fichier Compose maintenu utilise désormais un .env un fichier, une version plus récente de PostGIS, les images actuelles du frontend/backend et un installateur dédié qui demande les URL externes du frontend et du backend.
La source utilisait une pile Compose à trois services
La configuration Compose de 2025 contenait :
- un frontend SvelteKit appelé
web; - un service Django/backend appelé
server; - une base de données PostGIS/PostgreSQL appelée
db.
Le frontend exposait le port hôte 8015, le backend exposait un autre port hôte et des volumes Docker nommés stockaient les données de la base de données et les fichiers multimédias.
Le symptôme visible était un écran d’inscription qui ne faisait rien
L’application semblait s’installer correctement depuis l’application personnalisée de ZimaOS, mais l’utilisateur ne pouvait pas progresser au-delà de la connexion ou de l’inscription. Ce type de symptôme frontend peut être causé par :
- l’échec du frontend à joindre le backend ;
- l’échec du backend à joindre PostgreSQL ;
- des URL d’origine/CSRF incorrectes ;
- l’ordre de démarrage ou l’état de santé des services ;
- un proxy inverse modifiant l’URL externe effective.
Les journaux sources contenaient des éléments probants pour les deux premières couches, mais n’établissaient pas une cause racine définitive.
Le frontend expirait à plusieurs reprises lors de la récupération des données
Le journal du frontend signalait TypeError: fetch failed et ETIMEDOUT. Cela signifie que le processus frontend ne pouvait pas terminer une requête réseau qu’il s’attendait à voir aboutir.
Le fichier Compose d’origine utilisait PUBLIC_SERVER_URL=http://server:8000, ce qui est conceptuellement correct pour une communication de service à service au sein d’un même projet Compose. Cependant, modifier d’autres variables d’URL pour utiliser des adresses LAN ou des domaines proxy peut tout de même créer des incohérences entre l’origine et le navigateur/backend.
Le backend ne parvenait initialement pas à joindre PostgreSQL
Le journal du backend affichait à plusieurs reprises PostgreSQL est indisponible – mise en veille. Pendant ce temps, le journal de la base de données indiquait que PostGIS s’initialisait et finissait par être prêt.
Cela correspond au démarrage du backend avant que la base de données ne soit prête, à un paramètre de connexion à la base de données incorrect ou à un problème de réseau entre les services. Les sources ne contiennent pas suffisamment d’éléments pour distinguer ces possibilités de manière concluante.
L’ajout d’un tunnel Cloudflare n’a pas résolu le problème initial
L’utilisateur a essayé un tunnel Cloudflare après l’échec de la première installation, mais l’application ne fonctionnait toujours pas. Cela est attendu si le chemin frontend ↔ backend ↔ base de données sous-jacent est défaillant : un tunnel public peut exposer un service, mais il ne répare pas le réseau interne de Compose.
AdventureLog utilise actuellement une structure Compose maintenue plus simple
Le fichier Compose amont actuel d’AdventureLog utilise désormais :
-
ghcr.io/seanmorley15/adventurelog-frontend:latest; -
ghcr.io/seanmorley15/adventurelog-backend:latest; -
postgis/postgis:16-3.5; - un fichier
.envfichier pour la configuration des services ; - persistants
postgres_dataetadventurelog_mediavolumes.
Consultez la définition Compose actuelle d’AdventureLog au lieu de copier mot pour mot le fichier YAML du forum de 2025.
Configurez soigneusement les URL du frontend et du backend
L’installateur AdventureLog actuel demande l’URL du frontend et celle du backend, puis déduit la configuration des ports à partir de ces valeurs. Cela indique fortement que les valeurs d’URL et d’origine font partie du contrat de l’application, et ne sont pas de simples libellés.
Pour une configuration limitée au réseau local, utilisez de manière cohérente l’adresse IP ou le nom d’hôte réel de ZimaOS ainsi que les ports choisis. Avec un proxy inverse, configurez de manière cohérente les URL HTTPS publiques et évitez de mélanger localhost, les adresses du réseau local et les domaines publics sans comprendre quel processus utilise chaque valeur.
Ne conservez pas les mots de passe sources ni la SECRET_KEY
Le fichier Compose du forum contenait des valeurs d’exemple telles que changeme123 pour les secrets PostgreSQL et Django. Ce sont des exemples, pas des identifiants sûrs pour la production.
Générez des identifiants de base de données uniques et un secret d’application robuste. Si un secret réel a déjà été publié, remplacez-le.
Conserver la base de données et les médias avant de résoudre les problèmes de réinstallation
Désinstaller et réinstaller à répétition la pile peut créer un état difficile à comprendre si les volumes nommés sont conservés ou supprimés de manière inattendue. Déterminez si l’objectif est de :
- réutiliser la base de données et les médias existants ;
- commencez par une instance de test complètement vierge.
Sauvegardez tout élément important avant de supprimer les volumes Docker.
ZimaOS actuel : prise en charge plus directe de Compose standard
L’App Store ZimaOS 2.0 actuel et les flux de travail des applications personnalisées reposent sur Docker Compose standard et les métadonnées ZimaOS. Le comportement d’exécution de l’application — dépendances, variables d’environnement, ports, volumes, état de santé et réseaux — doit toujours être défini dans Compose.
Utilisez le modèle Compose actuel de ZimaOS pour adapter AdventureLog.
FAQ AdventureLog sur ZimaOS
Le fil source de 2025 a-t-il confirmé une solution fonctionnelle ?
Non. Le fil s’est terminé après que l’utilisateur a publié les journaux du frontend, du backend et de la base de données.
Quels étaient les indices les plus probants dans les sources ?
Des délais d’expiration lors des requêtes du frontend et un backend qui attendait continuellement PostgreSQL.
Faut-il réutiliser le fichier Compose de 2025 sans aucune modification ?
Non. Le fichier Compose maintenu d’AdventureLog, les images, la version de PostGIS et le modèle de configuration ont changé.
