El hilo de la fuente de 2025 nunca llegó a confirmar una instalación funcional de AdventureLog. El frontend se cargaba, pero el registro parecía no hacer nada. Los registros posteriores mostraron dos indicios más claros: el frontend informaba repetidamente: fetch failed con tiempos de espera de conexión, mientras que el backend repetía PostgreSQL no está disponible; esperando. El propio contenedor de la base de datos terminó inicializándose y escuchando con normalidad.
Estas pruebas apuntan a un problema de conectividad/configuración entre varios servicios, en lugar de a la simple conclusión de que «AdventureLog no funciona en ZimaOS». La implementación upstream actual de AdventureLog también ha cambiado: su Compose mantenido ahora utiliza un .env el archivo, PostGIS más reciente, imágenes actuales del frontend/backend y un instalador específico que solicita las URL externas del frontend y el backend.
La fuente utilizaba una pila Compose de tres servicios
El Compose de 2025 contenía:
- un frontend SvelteKit llamado
web; - un servicio Django/backend llamado
server; - una base de datos PostGIS/PostgreSQL llamada
db.
El frontend exponía el puerto de host 8015, el backend exponía otro puerto del host y los volúmenes Docker con nombre almacenaban los datos de la base de datos y los archivos multimedia.
El síntoma visible era una pantalla de registro que no hacía nada
La aplicación parecía instalarse correctamente desde Aplicación personalizada de ZimaOS, pero el usuario no podía avanzar en el inicio de sesión o el registro. Ese tipo de síntoma del frontend puede deberse a lo siguiente:
- el frontend no podía conectarse al backend;
- el backend no podía conectarse a PostgreSQL;
- URL de origen/CSRF incorrectas;
- el orden de inicio o el estado de salud de los servicios;
- un proxy inverso que cambiaba la URL externa efectiva.
Los registros de origen contenían pruebas de las dos primeras capas, pero no establecían una causa raíz definitiva.
El frontend agotaba repetidamente el tiempo de espera al realizar solicitudes
El registro del frontend indicaba TypeError: fetch failed y ETIMEDOUT. Eso significa que el proceso frontend no podía completar una solicitud de red que esperaba que tuviera éxito.
El Compose original utilizaba PUBLIC_SERVER_URL=http://server:8000, lo cual es conceptualmente correcto para la comunicación entre servicios dentro de un mismo proyecto de Compose. Sin embargo, cambiar otras variables de URL por direcciones LAN o dominios proxy todavía puede crear incompatibilidades entre el origen y el navegador/backend.
Al principio, el backend no podía conectarse a PostgreSQL
El registro del backend mostraba repetidamente PostgreSQL no está disponible; esperando. Mientras tanto, el registro de la base de datos mostró que PostGIS se estaba inicializando y que finalmente estaba listo.
Esto es compatible con que el backend se iniciara antes de que la base de datos estuviera lista, con una configuración incorrecta de conexión a la base de datos o con un problema de red entre servicios. La fuente no contiene pruebas suficientes para distinguir concluyentemente entre esas posibilidades.
Añadir un túnel de Cloudflare no solucionó el problema de origen
El usuario probó un túnel de Cloudflare después de que la primera instalación fallara, pero la aplicación siguió sin funcionar. Esto es esperable si la ruta subyacente frontend ↔ backend ↔ base de datos está dañada: un túnel público puede exponer un servicio, pero no repara la red interna de Compose.
AdventureLog usa actualmente una estructura de Compose mantenida y más sencilla
El Compose actual de AdventureLog en el repositorio original usa ahora:
-
ghcr.io/seanmorley15/adventurelog-frontend:latest; -
ghcr.io/seanmorley15/adventurelog-backend:latest; -
postgis/postgis:16-3.5; - compartido
.envarchivo - persistentes
postgres_datayadventurelog_mediavolúmenes.
Consulta la definición actual de Compose de AdventureLog en lugar de copiar literalmente el YAML del foro de 2025.
Configura deliberadamente las URL del frontend y del backend
El instalador actual de AdventureLog solicita la URL del frontend y la URL del backend, y deriva la configuración de puertos a partir de ellas. Esto indica claramente que los valores de URL/origen forman parte del contrato de la aplicación, no son etiquetas decorativas.
Para una configuración solo en la LAN, usa de forma coherente la IP o el nombre de host reales de ZimaOS y los puertos elegidos. Para un proxy inverso, configura de forma coherente las URL HTTPS públicas y evita mezclar localhost, las direcciones LAN y los dominios públicos sin entender qué proceso ve cada valor.
No conserves las contraseñas de origen ni SECRET_KEY
El Compose del foro incluía valores de marcador de posición como cámbiame123 para los secretos de PostgreSQL y Django. Son ejemplos, no credenciales seguras para producción.
Genera credenciales únicas para la base de datos y un secreto de aplicación seguro. Si alguna vez se ha publicado un secreto real, rótalo.
Conserva la base de datos y los archivos multimedia antes de solucionar problemas de reinstalación
Desinstalar y reinstalar repetidamente la pila puede crear un estado confuso si los volúmenes con nombre persisten o se eliminan inesperadamente. Decide si el objetivo es:
- reutiliza la base de datos y los archivos multimedia existentes;
- empieza con una instancia de prueba completamente limpia.
Haz una copia de seguridad de todo lo importante antes de eliminar volúmenes de Docker.
La versión actual de ZimaOS gestiona Compose estándar de forma más directa
La App Store 2.0 actual de ZimaOS y los flujos de trabajo de aplicaciones personalizadas se basan en Docker Compose estándar y los metadatos de ZimaOS. El comportamiento del tiempo de ejecución de la aplicación —dependencias, variables de entorno, puertos, volúmenes, estado y redes— sigue correspondiendo a Compose.
Usa el modelo actual de Compose de ZimaOS al adaptar AdventureLog.
Preguntas frecuentes sobre AdventureLog en ZimaOS
¿El hilo de fuentes de 2025 confirmó una solución funcional?
No. El hilo terminó después de que el usuario publicara los registros del frontend, el backend y la base de datos.
¿Cuáles fueron las pistas más contundentes de las fuentes?
Tiempos de espera agotados al obtener datos del frontend y un backend que espera repetidamente a PostgreSQL.
¿Debe reutilizarse sin cambios el Compose antiguo de 2025?
No. El Compose mantenido de AdventureLog, las imágenes, la versión de PostGIS y el modelo de configuración han cambiado.
