2025년 소스 스레드에서는 정상적으로 작동하는 AdventureLog 설치가 최종적으로 확인되지 않았습니다. 프런트엔드는 로드되었지만 가입 화면은 아무런 반응이 없는 것처럼 보였습니다. 이후 로그에서는 두 가지 더 강력한 단서가 나타났습니다. 프런트엔드가 반복해서 다음을 보고했습니다. fetch failed 연결 시간 초과가 발생하는 동안 백엔드는 반복해서 다음과 같이 출력했습니다. PostgreSQL을 사용할 수 없음 - 대기 중. 데이터베이스 컨테이너 자체는 결국 정상적으로 초기화되고 정상적으로 수신 대기했습니다.
이러한 증거는 단순히 “AdventureLog가 ZimaOS에서 작동하지 않는다”는 결론보다는 다중 서비스 연결/구성 문제를 가리킵니다. AdventureLog의 최신 업스트림 배포 방식도 변경되었습니다. 현재 유지 관리되는 Compose는 다음을 사용합니다. .env 파일, 최신 PostGIS, 최신 프런트엔드/백엔드 이미지, 그리고 외부 프런트엔드 및 백엔드 URL을 묻는 전용 설치 프로그램
소스에서는 3개 서비스로 구성된 Compose 스택을 사용했습니다
2025년 Compose에는 다음이 포함되어 있었습니다.
- 다음과 같은 SvelteKit 프런트엔드
web; - 다음과 같은 Django/백엔드 서비스
server; - 다음과 같은 PostGIS/PostgreSQL 데이터베이스
db.
프런트엔드는 호스트 포트 8015를 노출했고, 백엔드는 다른 호스트 포트를 노출했으며, 이름이 지정된 Docker 볼륨에는 데이터베이스와 미디어 데이터가 저장되었습니다.
눈에 보이는 증상은 아무런 반응이 없는 가입 화면이었습니다
애플리케이션은 ZimaOS Custom App에서 정상적으로 설치된 것처럼 보였지만, 사용자는 로그인/가입 단계로 진행할 수 없었습니다. 이러한 프런트엔드 증상은 다음과 같은 원인으로 발생할 수 있습니다.
- 프런트엔드가 백엔드에 연결하지 못함
- 백엔드가 PostgreSQL에 연결하지 못함
- 잘못된 출처/CSRF URL
- 서비스 시작 순서 또는 상태 확인 문제
- 리버스 프록시가 실제 외부 URL을 변경했을 가능성
소스 로그에는 처음 두 계층의 문제를 뒷받침하는 증거가 있었지만, 최종적인 단일 원인은 확인되지 않았습니다.
프런트엔드는 데이터를 가져오는 동안 반복적으로 시간 초과가 발생했습니다
프런트엔드 로그에는 다음 내용이 보고되었습니다 TypeError: fetch failed 및 ETIMEDOUT. 즉, 프런트엔드 프로세스가 성공할 것으로 예상한 네트워크 요청을 완료하지 못했다는 뜻입니다.
원래 Compose 설정에는 다음이 사용되었습니다 PUBLIC_SERVER_URL=http://server:8000. 이는 하나의 Compose 프로젝트 내부에서 서비스 간 통신을 수행하는 방식으로는 개념적으로 올바릅니다. 그러나 다른 URL 변수를 LAN 주소나 프록시 도메인으로 변경하면 출처 및 브라우저/백엔드 불일치가 발생할 수 있습니다.
백엔드는 처음에 PostgreSQL에 연결할 수 없었습니다
백엔드 로그에는 다음 내용이 반복해서 출력되었습니다 PostgreSQL을 사용할 수 없음 - 대기 중. 한편 데이터베이스 로그에는 PostGIS가 초기화되고 결국 준비 완료 상태가 된 것으로 나타났습니다.
이는 데이터베이스가 준비되기 전에 백엔드가 시작되었거나, DB 연결 설정이 잘못되었거나, 서비스 네트워크에 문제가 있다는 설명과 일치합니다. 소스에 포함된 정보만으로는 이 가능성들을 확정적으로 구분할 수 없습니다.
Cloudflare Tunnel 추가로 원래 문제가 해결되지는 않았습니다
사용자는 첫 번째 설치 실패 후 Cloudflare Tunnel을 시도했지만 애플리케이션은 여전히 작동하지 않았습니다. 기본 프런트엔드 ↔ 백엔드 ↔ 데이터베이스 경로가 끊겨 있다면 이는 예상 가능한 결과입니다. 퍼블릭 터널은 서비스를 외부에 노출할 수 있지만 내부 Compose 네트워킹을 복구하지는 않습니다.
현재 AdventureLog는 더 단순하고 관리가 용이한 Compose 레이아웃을 사용합니다
현재 AdventureLog의 업스트림 Compose는 이제 다음을 사용합니다.
-
ghcr.io/seanmorley15/adventurelog-frontend:latest; -
ghcr.io/seanmorley15/adventurelog-backend:latest; -
postgis/postgis:16-3.5; - 공유
.env구성 파일; - 영구
postgres_data및adventurelog_media볼륨.
2025년 포럼 YAML을 그대로 복사하는 대신 현재 AdventureLog Compose 정의를 검토하세요.
프런트엔드 및 백엔드 URL을 명확하게 구성하세요
현재 AdventureLog 설치 프로그램은 프런트엔드 URL과 백엔드 URL을 요청하고 이 값을 바탕으로 포트 구성을 결정합니다. 이는 URL/오리진 값이 단순한 표시용 레이블이 아니라 애플리케이션 계약의 일부라는 강력한 신호입니다.
LAN 전용 설정에서는 실제 ZimaOS IP/호스트 이름과 선택한 포트를 일관되게 사용하세요. 리버스 프록시를 사용하는 경우 공개 HTTPS URL을 일관되게 구성하고 다음을 혼용하지 마세요. localhost각 값이 어느 프로세스에서 사용되는지 이해하지 않은 채 LAN 주소와 공개 도메인을 사용하지 마세요.
원본 비밀번호와 SECRET_KEY를 그대로 사용하지 마세요
포럼 Compose에는 다음과 같은 자리 표시자 값이 포함되어 있습니다. changeme123 이는 예시일 뿐 안전한 프로덕션 자격 증명이 아닙니다.
PostgreSQL 및 Django 시크릿에 사용할 고유한 데이터베이스 자격 증명과 강력한 애플리케이션 시크릿을 생성하세요. 실제 시크릿이 공개적으로 게시된 적이 있다면 교체하세요.
재설치를 문제 해결하기 전에 데이터베이스와 미디어 유지
이름이 지정된 볼륨이 유지되거나 예기치 않게 삭제되면 스택을 반복해서 제거하고 재설치할 때 혼란스러운 상태가 발생할 수 있습니다. 목표가 무엇인지 결정하세요:
- 기존 데이터베이스/미디어를 재사용합니다;
- 완전히 깨끗한 테스트 인스턴스에서 시작하세요.
Docker 볼륨을 삭제하기 전에 중요한 데이터를 백업하세요.
현재 ZimaOS는 표준 Compose를 보다 직접적으로 처리합니다
현재 ZimaOS App Store 2.0 및 커스텀 앱 워크플로는 표준 Docker Compose와 ZimaOS 메타데이터를 기반으로 합니다. 의존성, 환경 변수, 포트, 볼륨, 상태 점검 및 네트워크와 같은 애플리케이션 런타임 동작은 여전히 Compose에서 관리합니다.
AdventureLog를 적용할 때는 현재 ZimaOS Compose 모델을 사용하세요.
ZimaOS의 AdventureLog FAQ
2025년 원본 스레드에서 작동하는 해결 방법을 확인했나요?
아니요. 사용자가 프런트엔드, 백엔드 및 데이터베이스 로그를 게시한 후 스레드가 종료되었습니다.
가장 강력한 원본 단서는 무엇이었나요?
프런트엔드의 가져오기 시간 초과와 PostgreSQL을 반복해서 기다리는 백엔드.
기존 2025년 Compose를 수정 없이 재사용해야 하나요?
아니요. AdventureLog에서 관리하는 Compose, 이미지, PostGIS 버전 및 구성 모델이 변경되었습니다.
