2025年のソーススレッドでは、AdventureLogのインストールが正常に動作したことは確認されませんでした。フロントエンドは読み込まれましたが、サインアップをクリックしても何も起こらないように見えました。その後のログには、さらに有力な2つの手がかりが示されました。フロントエンドは繰り返し次のように報告していました フェッチに失敗しました 接続タイムアウトが発生する一方で、バックエンドは繰り返し次のように報告していました PostgreSQLは利用できません - 待機中データベースコンテナ自体は最終的に初期化され、正常に接続を受け付けていました。
この証拠は、単純に「AdventureLogはZimaOSでは動作しない」という結論ではなく、複数サービス間の接続または設定の問題を示しています。AdventureLogの現在の上流デプロイ方法も変更されており、現在は保守されているComposeで次のものを使用しています .env ファイル、新しいPostGIS、現行のフロントエンド／バックエンドイメージ、そして外部フロントエンドURLとバックエンドURLの入力を求める専用インストーラー。
ソースでは3サービス構成のComposeスタックが使用されていた
2025年のComposeには、次のサービスが含まれていました。
- SvelteKitフロントエンドである
web; - Django／バックエンドサービスである
server; - PostGIS/PostgreSQLデータベースである
db.
フロントエンドはホストポート8015を公開し、バックエンドは別のホストポートを公開していました。また、名前付きDockerボリュームにデータベースとメディアのデータが保存されていました。
目に見える症状は、何も起こらないサインアップ画面だった
アプリケーションはZimaOSのカスタムアプリから正常にインストールされたように見えましたが、ユーザーはログイン／サインアップを進められませんでした。この種のフロントエンドの症状は、次の原因で発生する可能性があります。
- フロントエンドがバックエンドに接続できない。
- バックエンドがPostgreSQLに接続できない。
- オリジン／CSRF URLが正しくない。
- サービスの起動順序またはヘルス状態。
- リバースプロキシが実質的な外部URLを変更している。
ソースログには最初の2つの層に関する証拠は含まれていましたが、最終的な根本原因を1つに確定するには至りませんでした。
フロントエンドはフェッチ中に繰り返しタイムアウトした
フロントエンドのログには次の内容が報告されていました TypeError: fetch failed および ETIMEDOUTつまり、フロントエンドプロセスは、成功するはずのネットワークリクエストを完了できませんでした。
元のComposeでは次のようになっていました PUBLIC_SERVER_URL=http://server:8000これは、1つの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とバックエンドURLを意図的に設定する
現在のAdventureLogインストーラーはフロントエンドURLとバックエンドURLを尋ね、それらからポート設定を導出します。これは、URLやオリジンの値が単なる表示用ラベルではなく、アプリケーションの契約の一部であることを示す強い手がかりです。
LANのみの構成では、実際のZimaOSのIPアドレスまたはホスト名と、選択したポートを一貫して使用してください。リバースプロキシを使用する場合は、公開HTTPS URLを一貫して設定し、localhostとLANアドレスやパブリックドメインを混在させないでください。 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のバージョン、設定モデルが変更されています。
