A discussão da fonte de 2025 nunca chegou a uma instalação confirmadamente funcional do AdventureLog. O frontend carregava, mas o registo parecia não fazer nada. Os registos posteriores mostraram duas pistas mais fortes: o frontend indicava repetidamente: falha ao obter dados com tempos limite de ligação, enquanto o backend indicava repetidamente PostgreSQL indisponível — a aguardar. O próprio contentor da base de dados acabou por ser inicializado e ficou a escutar normalmente.
Essa evidência aponta para um problema de conectividade/configuração entre vários serviços, e não para uma simples conclusão de que «o AdventureLog não funciona no ZimaOS». A implementação upstream atual do AdventureLog também mudou: o Compose mantido atualmente utiliza um .env ficheiro, uma versão mais recente do PostGIS, imagens atuais do frontend/backend e um instalador dedicado que solicita os URLs externos do frontend e do backend.
A fonte utilizava uma pilha Compose com três serviços
O Compose de 2025 continha:
- web
um frontend SvelteKit chamado; - server
um serviço Django/backend chamado; - uma base de dados PostGIS/PostgreSQL chamada
db.
O frontend expunha a porta de anfitrião 8015, o backend expunha outra porta de anfitrião e volumes Docker nomeados armazenavam os dados da base de dados e dos ficheiros multimédia.
O sintoma visível era um ecrã de registo que não fazia nada
A aplicação parecia instalar-se com êxito a partir da aplicação personalizada do ZimaOS, mas o utilizador não conseguia avançar no início de sessão/registo. Este tipo de sintoma no frontend pode ser causado por:
- o frontend não conseguia aceder ao backend;
- o backend não conseguia aceder ao PostgreSQL;
- URLs de origem/CSRF incorretos;
- a ordem de arranque ou o estado de saúde dos serviços;
- um proxy inverso a alterar o URL externo efetivo.
Os registos da fonte continham evidências para as duas primeiras camadas, mas não estabeleciam uma causa-raiz final.
O frontend excedia repetidamente o tempo limite ao obter dados
O registo do frontend indicava TypeError: fetch failed e ETIMEDOUT. Isso significa que o processo frontend não conseguia concluir um pedido de rede que deveria ter sido bem-sucedido.
O Compose original utilizava PUBLIC_SERVER_URL=http://server:8000, o que está conceptualmente correto para a comunicação entre serviços dentro de um único projeto Compose. No entanto, alterar outras variáveis de URL para endereços da LAN ou domínios de proxy pode ainda criar incompatibilidades entre a origem e o navegador/backend.
Inicialmente, o backend não conseguiu aceder ao PostgreSQL
O registo do backend apresentava repetidamente PostgreSQL indisponível — a aguardar. Entretanto, o registo da base de dados mostrou o PostGIS a inicializar e, por fim, a ficar pronto.
Isto é compatível com um backend que arranca antes de a base de dados estar pronta, uma definição de ligação à BD incorreta ou um problema na rede dos serviços. A fonte não contém evidências suficientes para distinguir conclusivamente entre estas possibilidades.
Adicionar um Cloudflare Tunnel não resolveu o problema original
O utilizador tentou um Cloudflare Tunnel após a primeira instalação falhada, mas a aplicação continuou sem funcionar. Isto é expectável se o percurso frontend ↔ backend ↔ base de dados subjacente estiver interrompido: um túnel público pode expor um serviço, mas não repara a rede interna do Compose.
O AdventureLog atual utiliza uma estrutura de Compose mantida mais simples
O Compose upstream atual do AdventureLog utiliza agora:
-
ghcr.io/seanmorley15/adventurelog-frontend:latest; -
ghcr.io/seanmorley15/adventurelog-backend:latest; -
postgis/postgis:16-3.5; - um
.envficheiro para a configuração dos serviços; - persistentes
postgres_dataeadventurelog_mediavolumes.
Consulte a definição atual do Compose do AdventureLog em vez de copiar literalmente o YAML do fórum de 2025.
Configure Deliberadamente os URLs do Frontend e do Backend
O instalador atual do AdventureLog solicita o URL do frontend e o URL do backend e deriva deles a configuração das portas. Isto é um forte indício de que os valores de URL/origem fazem parte do contrato da aplicação, não são apenas rótulos decorativos.
Para uma configuração apenas na LAN, utilize consistentemente o endereço IP/nome de anfitrião real do ZimaOS e as portas escolhidas. Para um proxy inverso, configure consistentemente os URLs HTTPS públicos e evite misturar localhost, endereços da LAN e domínios públicos sem compreender qual o processo que vê cada valor.
Não mantenha as palavras-passe de origem nem a SECRET_KEY
O Compose do fórum incluía valores de marcador, como changeme123 para os segredos do PostgreSQL e do Django. São exemplos, não credenciais seguras para produção.
Gere credenciais únicas para a base de dados e um segredo de aplicação forte. Se um segredo real tiver sido alguma vez publicado, altere-o.
Conservar a Base de Dados e os Meios Antes de Diagnosticar Reinstalações
Desinstalar e reinstalar repetidamente a pilha pode criar um estado confuso se os volumes nomeados persistirem ou forem eliminados inesperadamente. Decida se o objetivo é:
- reutilize a base de dados/meios existentes;
- comece por uma instância de teste completamente limpa.
Faça uma cópia de segurança de tudo o que for importante antes de eliminar volumes do Docker.
O ZimaOS atual lida diretamente com o Compose padrão
A App Store 2.0 e os fluxos de aplicações personalizadas atuais do ZimaOS baseiam-se no Docker Compose padrão e nos metadados do ZimaOS. O comportamento em execução da aplicação — dependências, variáveis de ambiente, portas, volumes, estado de funcionamento e redes — continua a ser definido no Compose.
Utilize o modelo atual de Compose do ZimaOS ao adaptar o AdventureLog.
FAQ do AdventureLog no ZimaOS
A discussão de 2025 confirmou uma solução funcional?
Não. O tópico terminou depois de o utilizador publicar os registos do frontend, do backend e da base de dados.
Quais foram as pistas mais fortes da fonte?
Tempos limite de obtenção do frontend e um backend que aguardava repetidamente pelo PostgreSQL.
Deverá o Compose antigo de 2025 ser reutilizado sem alterações?
Não. O Compose mantido do AdventureLog, as imagens, a versão do PostGIS e o modelo de configuração foram alterados.
