World Monitor ローカル構築ガイド：Docker、Ollama、PMTiles、オフライン情報パネル

World Monitor は、ニュース、市場、航空、地理的リスク、インフラストラクチャ、公共情報のデータを集約するリアルタイムダッシュボードです。 GitHub Trending には 1 週間で約 13,231 個のスターが追加されましたが、「フロントエンドを開くことができる」ことと「完全にオフラインで実行できる」ことは 2 つの異なる導入目標です。この記事では、まずコンポーネントとネットワークの依存関係を分離し、次にソースコード開発、コンテナフロントエンド、ローカル AI の概要に関する 3 つの検証可能なパスを示します。

必要なオフライン範囲を先に決める

プロジェクトのドキュメントでは、プライバシーモデルの 3 つのカテゴリについて説明しています。最も簡単な方法は、アプリをローカルで開きますが、引き続きパブリック API とクラウド LLM をリクエストします。 2 番目のタイプは、デスクトップ上の Ollama、LM Studio、llama.cpp、または vLLM と連携して、ニュースの概要がローカルマシン上に残り、他のデータソースがオンラインのままになるようにするものです。 3 番目のカテゴリは分離ネットワークです。ローカルモデル、ローカル PMTiles、事前に準備されたデータスナップショット、およびライブ外部ソースの無効化です。 3 番目のカテゴリは、フライト、マーケット、RSS、リスクフィード自体を更新する必要があるため、Docker コンテナーを使用して自動的に実行することはできません。開始する前に、アクセスが許可されているドメイン名、データ更新時間の要件、クラウドが許可されているかどうかの概要を書き留めてください。

World Monitor は Web ページだけでは動かない

フロントエンドは Vanilla TypeScript アプリケーションであり、地図は MapLibre GL、deck.gl、globe.gl などのコンポーネントによってレンダリングされます。サーバー部分には、エッジハンドラー、RPC ゲートウェイ、キャッシュ、およびデータシードタスクが含まれます。 AIS Relay は、一部のリアルタイムストリーミングおよび定期的なデータを処理します。 Redis は、キャッシュ、スロットリング、および複数のリクエストが同じデータを同時に更新するのを防ぐために使用されます。デスクトップは Node.js サイドカーを備えた Tauri を使用します。 PMTiles は、ベースマップをオブジェクトストレージまたは LAN HTTP サービスに配置できます。したがって、セルフホスティングでは、どのコンポーネントが独自に実行され、どのコンポーネントが上流のサービスを借用し続けるかを明確にする必要があります。

導入前ライセンス

リポジトリは AGPL-3.0 であり、商業用途向けの追加手順が含まれています。個人、研究、教育での使用は、帰属およびライセンス条件に従って自己ホストされる場合があります。商用 SaaS、ブランド解除、または再パッケージ化では、プロジェクトの商用ライセンス要件を確認する必要があります。「コードは公的にダウンロードできる」ということは、クローズドソースとして無条件に販売できるという意味であることを理解してはいけません。外部サービスの提供を計画する場合は、まずリポジトリにある LICENSE および README 許可フォームをお読みください。

Node.js 22 と基本ツール

を準備するプロジェクト変更ログでは、開発ベースラインとしてNode.js 22 が修正されています。 WSL2 の使用をお勧めします。Windows、Linux、macOS 上の Ubuntu は直接操作できます。

1
2
3
4


node --version
npm --version
git --version
make --version

ノードのメインバージョンが 22 ではない場合、nvm を使用して切り替えます:

1
2
3


nvm install 22
nvm use 22
node --version

システムノードと nvm ノード間でグローバルパッケージを混在させないでください。

ソースコード

から完全な開発パネルを起動します最初に公式リポジトリをフォークするか直接クローンします:

1
2
3


git clone https://github.com/koala73/worldmonitor.git
cd worldmonitor
git rev-parse HEAD

コミット SHA を保存すると、その後のドキュメントと構成の変更を特定のバージョンまで追跡できます。公式貢献ドキュメントでは、統一されたインストールターゲットが提供されています:

1

make install

buf、sebuf プラグイン、npm 依存関係、Playwright ブラウザーを準備します。ヘルプのみを表示するには、

1

make help

を実行します。フルバリアントの開発サーバー:

1

npm run dev

デフォルトのアドレスは http://localhost:3000 です。

variant は別リポジトリではなく構成の違い

World Monitor は、バリアントを介してパネル、マップレイヤー、更新サイクル、およびデフォルトのデータソースを制御します。テクノロジー、財務、および完全なパネルは個別に起動できます:

1
2


npm run dev:tech
npm run dev:finance

実稼働ビルドには、対応するコマンド

1
2
3


npm run build
npm run build:tech
npm run build:finance

もあります。バリアントを切り替えると、一部の設定がリセットされます。異なるブラウザーバリアントの localStorage を同じ構成として扱わないでください。

環境変数はデータソース

に従って 1 つずつオンになります。サンプルファイルをコピーします:

1

cp .env.example .env.local

すべての API キーを一度に入力しないでください。認証情報を必要としないパネルから開始し、フロントエンド、マップ、および基本的な RPC が動作していることを確認します。ニュース、マーケット、フライト、LLM サプライヤーを 1 つずつ追加します。変数が追加されるたびに、サービスが再起動され、ネットワーク要求がチェックされます。 .env.local は Git に入りません:

1
2


git status --short
git check-ignore .env.local

2 番目の項目が出力されない場合は、最初に .gitignore を確認し、実キーの入力を続けないでください。

ホスト型フロントエンドの Docker ルート

リポジトリ内の docker/Dockerfile はマルチアーキテクチャイメージを構築し、nginx は SPA を提供し、API リクエストをアップストリームにプロキシします。最初にローカルでビルドします:

1
2


docker build -f docker/Dockerfile -t worldmonitor:local .
docker image inspect worldmonitor:local

実行する前に、Dockerfile の公開ポートと nginx 構成を確認してください。ポートを推測しないでください:

1
2


docker image inspect worldmonitor:local \
  --format '{{json .Config.ExposedPorts}}'

画像露出 80 を想定し、ループバックのみのマッピングテストが利用可能:

1
2
3


docker run --rm --name worldmonitor-test \
  -p 127.0.0.1:8080:80 \
  worldmonitor:local

実際のポートが異なる場合は、ミラーリングチェックの結果が優先されます。

コンテナフロントエンドは、すべての API がローカライズされることを意味するわけではありません

ブラウザの開発者ツールの [ネットワーク] パネルを開きます。ページを更新し、ドメイン名ごとにリクエストをグループ化します。 Vercel、Railway、Upstash、サードパーティのニュース、またはマーケットインターフェイスへのアクセス要求は、現在もクラウドへの依存関係が存在することを示しています。「Web ページは自分のサーバーから送信されている」ということを使用して、「データは LAN から出ていない」と推測しないでください。分離が必要な場合は、API エンドポイントを項目ごとに置き換えるか、ローカルで機能しないパネルを無効にします。

Ollama によるローカルダイジェスト

の提供 World Monitor のネイティブ LLM ルートは、OpenAI 互換サービスをサポートし、Ollama、LM Studio、llama.cpp、および vLLM モデルを検出できます。 Ollama のインストール後にサービスを確認します:

1
2
3


ollama --version
ollama list
curl http://127.0.0.1:11434/api/tags

ネイティブリソースに適したコマンドモデルをプルします:

1

ollama pull qwen3:8b

OpenAI 互換エンドポイントを再テストします:

1

curl http://127.0.0.1:11434/v1/models

アプリケーションで、ベース URL がループバックアドレスを指すようにし、実際のモデル ID を選択します。

ローカル LLM フォールバックチェーンにはアクティブな検証が必要

プロジェクトのドキュメントでは、ネイティブ LLM、Groq、OpenRouter、ブラウザ T5 を含むフォールバックシーケンスの概要が説明されています。データがネットワークから流出するのを防ぐことが目的の場合、単に Ollama を構成するだけでは十分ではありません。また、クラウドキーを削除し、関連するドメイン名をブロックし、ローカルタイムアウト後にブラウザがサイレントにロールバックしないことを確認します。 Ollama サービスを停止します:

1

sudo systemctl stop ollama

改めて概要をトリガーします。厳密にオフラインの構成では、クラウドの概要を生成するのではなく、ローカルサービスが利用できないことを明確に示す必要があります。

PMTiles はベースマップの依存関係

を解決します従来のマップは、ビューポートごとにオンラインタイルを継続的に要求します。 PMTiles は、タイルをローカルディスク、NAS、オブジェクトストレージ、または通常の HTTP サービスに配置できる個別のアーカイブに編成します。ファイルを準備したら、最初に最小限の HTTP サービスを実行します:

1

python3 -m http.server 9000 --directory /srv/pmtiles

ブラウザから PMTiles ファイルにアクセスし、範囲リクエストがサポートされていることを確認します。 Range サポートがないと、マップは大きなファイル全体をダウンロードしようとしたり、タイルを見つけられなかったりする可能性があります。リバースプロキシは、Range および Accept-Ranges に関連するヘッダーを保持する必要があります。

Cloudflare R2 と LAN ストレージのどちらを選択するか

R2 はパブリックネットワークサービスに適しており、発信元サイトの帯域幅を削減し、オブジェクトレベルのアクセスを提供できます。 LAN MinIO、NAS、または nginx は、隔離された環境に適しています。ベースマップファイルは大きくなる可能性があり、公開前にサイズとハッシュを記録します:

1
2


sha256sum world.pmtiles
du -h world.pmtiles

クライアントが URL を構成した後、ブラウザを使用してリクエストを確認し、206 Partial Content を返します。

Redis はローカルトライアルのハードしきい値ではありません

1 人による開発では、完全なキャッシュシステムを導入する必要はありません。複数人またはパブリックネットワークサービスでは、Redis がリフレッシュストームを制御し、シード結果をキャッシュし、トラフィックを制限する必要があります。ローカル Redis を開始します:

1
2


docker run --rm --name worldmonitor-redis \
  -p 127.0.0.1:6379:6379 redis:7-alpine

検証:

1

docker exec worldmonitor-redis redis-cli ping

PONG が返される必要があります。 Redis はパブリックネットワークに直接公開しないでください。また、ホスト間アクセスのデフォルトのパスワードなし構成に依存しないでください。

外部データソースに障害が発生した場合の責任の所在を決定する方法

まず、ブラウザー要求の URL、ステータスコード、応答時間を確認します。 401 または 403 は通常、キー、クォータ、または承認範囲です。 429 はレート制限を示します。再試行を追加すると、問題がさらに深刻になる可能性があります。 5xx は、独自のプロキシ、アップストリームサービス、およびキャッシュ層を区別する必要があります。空の配列は必ずしも障害ではなく、地域および時間範囲のデータがない可能性があります。空白のパネルのスクリーンショットを撮るだけではなく、リクエスト ID とレスポンスヘッダーを保存してください。

AIS とリアルタイムストリーミングは静的構造

に置き換えることはできません配送 AIS、フライト、および GPS 干渉レイヤーは、継続的なデータストリームまたは定期的なシードに依存します。純粋な nginx SPA は、既存のデータを表示し、アップストリームインターフェイスを呼び出すことしかできません。関連するフローをセルフホストする必要がある場合は、scripts/ais-relay.cjs とデプロイメント構成を読んで、データプロバイダーのアクセス許可を確認してください。公開 Web ページに表示されるデータソースを無条件にミラーリングして再公開しないでください。

ヘルスチェックとデータの鮮度監視をオンにする

アプリケーションは 200 を返すことがありますが、これはデータが更新されていることを意味するものではありません。モニタリングは、静的ページ、API エンドポイント、シードの鮮度という少なくとも 3 つのレベルに分かれています。各データソースの最後の成功時間と連続失敗回数を記録します。ニュースがまだ更新されており、市場が低迷しているときは、サイト全体が完全に健全であるとマークされるべきではありません。

1
2
3
4


npm run typecheck
npm run test:data
npm run test:e2e
npm run build:full

をビルドする前にプロジェクト独自のチェックを実行しますコマンドの存在は、現在のリポジトリ package.json および make help に基づいています。データテストが失敗した場合、失敗の原因を削除して CI を緑色にしないでください。まずはフォーマットが変わっていないか確認してください。 E2E にはブラウザーの依存関係と安定したテストデータが必要で、コンテナー CI には予約された共有メモリが必要です。

リバースプロキシは必要な入り口のみを開きます

パブリックネットワークデプロイメントでは HTTPS を使用し、管理エンド、Redis、Ollama、および内部シードエンドポイントをプライベートネットワークに残します。デフォルトでは、Ollama をインターネットに直接公開すべきではありません。フロントエンドと API が別のドメインにある場合は、CORS 許可リストを明示的に設定します。どのオリジンでも資格情報を保持できるような組み合わせは使用しないでください。

実際に切断訓練を行う

Service Worker、ブラウザーキャッシュ、および IndexedDB には古いデータが保持されたままであるため、パネルをロードした後にインターネットから切断すると、誤検知が発生する可能性があります。まずテストプロファイルをクリアし、外部ドメイン名をブロックしてから、アプリケーションを再度開きます。どのパネルが正常で、どのパネルが古いキャッシュを表示し、どのパネルがエラーを報告するかを記録します。タイムスタンプによってデータの有効期限が切れていることが明確に示されていることを確認してください。オフラインモードでは、古い情報をリアルタイム情報として偽装するのではなく、適切に機能を低下させる必要があります。

のアップグレード時にバリアントとマップの構成を保持するアップグレードする前に、コミット、.env.local 変数名、PMTiles URL、Redis スキーマ、およびリバースプロキシ構成を保存します。

1
2
3


git fetch --tags
git log --oneline --decorate -10
git diff -- .env.example docker/ deploy/

最初に新しい作業ツリーを構築します。実行ディレクトリを直接上書きしないでください。フロントエンドのlocalStorageの設定形式は変更される可能性があります。アップグレード後のバリアント、レイヤー、更新サイクルを確認してください。

セルフホスティングによって完成した決定リスト

必要なバリアントを含むページを構築できます。
Docker イメージポートは推測ではなく検査から得られます。
すべての API キーは Git の外部にあります。
オンプレミス LLM が失敗した場合でも、サイレントにクラウドに移行することはありません。
PMTiles は Range リクエストを返します。
Redis、Ollama、および内部サービスはパブリックネットワークに公開されません。
各リアルタイムデータソースには最終更新時刻があります。
オフラインテストでは、キャッシュと実際の可用性を区別できます。
商用利用のライセンスが確認されました。

World Monitor のセルフホスティングの境界は、保持するライブデータソースの数によって異なります。最初にネットワークの依存関係を明確に示してから、ローカルフロントエンド、プライバシーサマリー、または完全な分離のいずれを使用するかを決定する方が、「1 つの Docker コマンド」を直接追求するよりも信頼性が高くなります。

プロジェクト情報

【ワールドモニター公式倉庫】(https://github.com/koala73/worldmonitor)
ワールドモニターアーキテクチャドキュメント
ワールドモニター更新記録
ワールドモニターの貢献と開発ドキュメント