Posted inホームラボ

DockerでProwlarrを構築：HomeLabメディアスタック向けインデクサーの一元管理と自動同期

HomeLab tutorial - IT technology blog
HomeLab tutorial - IT technology blog

背景と導入理由：HomeLabにおけるインデクサーの乱立（スプロール化）を解消する

セルフホストによるメディアサーバーの構築は、最初は小さな構成から始まることがほとんどです。Jellyfinをインストールし、テレビ番組用にSonarrを追加し、映画用にRadarrを導入します。やがて音楽用にLidarr、字幕用にBazarrも追加することになるでしょう。しかし、そうなるとトラッカーのメンテナンスが大きな負担になり始めます。

例えば、4つの異なる*arr系アプリに対して5つのインデクサーを追加する場合を考えてみてください。APIキーの入力、レート制限の調整、カテゴリーIDの選択などを20回も個別に行う必要があります。さらに、プライベートトラッカーがドメインを変更したり、Cloudflareによる認証チャレンジを導入したりした際には、すべてのダッシュボードを巡回してまったく同じ設定作業を繰り返さなければなりません。

Prowlarrはこの煩雑な問題を一挙に解決してくれます。中央プロキシおよび設定ハブとして機能し、各種インデクサーと下流のサービス群との間に位置します。Prowlarrでトラッカーを一度定義すれば、数秒後にはREST API経由でSonarr、Radarr、Lidarrへその設定が自動プッシュされます。インデクサーの停止や設定変更が発生しても、修正は1箇所だけで完了します。

インストール：Docker Composeを使ったProwlarrのデプロイ

Prowlarrをコンテナ化することで、ホストOSをクリーンに保ち、移行作業もシンプルになります。ここではLinuxServer.ioのイメージを使用し、カスタムのDockerブリッジネットワーク上で運用することで、コンテナ名を使って他のサービスと直接通信できるようにします。

1. ディレクトリ構造とネットワークの準備

ProwlarrのSQLiteデータベースや設定ファイルを保存するディレクトリを作成し、Dockerボリュームの権限エラーを防ぐために現在のユーザーのUIDとGIDを確認します。

# 設定データ永続化用のディレクトリを作成
mkdir -p ~/homelab/prowlarr/config
cd ~/homelab/prowlarr

# 現在のユーザーIDとグループIDを確認
id
# 出力例: uid=1000(homelab) gid=1000(homelab)

# 共有ブリッジネットワークが存在しない場合は作成
docker network create media-network 2>/dev/null || true

2. Docker Compose定義ファイルの作成

ディレクトリ内にdocker-compose.ymlファイルを作成します。

services:
  prowlarr:
    image: lscr.io/linuxserver/prowlarr:latest
    container_name: prowlarr
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
    volumes:
      - ./config:/config
    ports:
      - "9696:9696"
    networks:
      - media-network
    restart: unless-stopped

networks:
  media-network:
    external: true

3. コンテナの起動

バックグラウンドでコンテナを起動し、初期化ログをリアルタイムで確認します。

docker compose up -d

# 起動ログを追跡してデータベーススキーマの初期化を確認
docker compose logs -f prowlarr

Listening on http://0.0.0.0:9696/というログが出力されていることを確認してください。準備ができたら、ブラウザでhttp://<サーバーのIPアドレス>:9696にアクセスします。

設定：インデクサー、FlareSolverr、および自動同期

1. 最初のインデクサーの追加とテスト

Prowlarrのダッシュボードで以下の手順を実行します。

  1. 左側メニューのIndexersをクリックし、Add Indexer（+アイコン）をクリックします。
  2. プロバイダーを選択します（Newznab/NinjaCentralなどのUsenetインデクサー、または1337xなどのTorrentトラッカー）。
  3. PasskeyまたはAPIトークンを入力し、Testをクリックします。
  4. 緑色のチェックマークが表示されれば、Prowlarrが正常に接続し、エンドポイントを検証して機能一覧を取得できたことを示します。Saveをクリックします。

2. FlareSolverrによるCloudflareチャレンジの回避

公開Torrentトラッカーの多くは、Cloudflare TurnstileやJavaScriptチャレンジを導入しており、自動化されたcurlリクエストをブロックします。FlareSolverrはヘッドレスChromiumブラウザを起動してこれらのチャレンジを解決し、有効なセッションCookieを返すことでブロックを回避します。これをdocker-compose.ymlに直接追加します。

  flaresolverr:
    image: ghcr.io/flaresolverr/flaresolverr:latest
    container_name: flaresolverr
    environment:
      - LOG_LEVEL=info
      - TZ=America/New_York
    ports:
      - "8191:8191"
    networks:
      - media-network
    restart: unless-stopped

docker compose up -dを実行してコンテナを起動します。ProwlarrでSettings > Indexersを開き、Proxiesの下にある+をクリックしてFlareSolverrを選択します。Hostにhttp://flaresolverr:8191を指定し、タイムアウトを60秒に設定して保存します。これで、Prowlarrはボット対策チャレンジをFlareSolverr経由で自動的に処理するようになります。

3. 下流アプリケーションとのAPI連携

ここからが自動化の真骨頂です。各*arrツールを手動で設定する代わりに、Prowlarrと連携させます。

  1. Settings > Appsに移動し、+ボタンをクリックします。
  2. 対象のアプリ（例：SonarrやRadarr）を選択します。
  3. Sync LevelをFull Syncに設定します。これを有効にすると、Prowlarrがインデクサーのライフサイクル全体を管理し、新規追加、定義の更新、無効になったトラッカーの削除などを自動で行います。
  4. Prowlarr Serverにhttp://prowlarr:9696を設定します。両コンテナは同じmedia-networkブリッジネットワークを共有しているため、Dockerの内部DNSによってホスト名が自動解決されます。
  5. Radarr/Sonarr Serverに対象コンテナのURI（例：http://sonarr:8989）を入力します。
  6. SonarrまたはRadarr側で、Settings > General > Security > API KeyからAPIキーをコピーし、Prowlarrに貼り付けます。
  7. Testをクリックします。接続が確認できたらSaveをクリックします。

SonarrやRadarrに切り替えてSettings > Indexersを確認すると、即座にトラッカーが一覧表示され、Prowlarrによって一元管理されていることを示す鍵アイコンが付与されているはずです。

検証とモニタリング：ヘルスチェックとクエリパフォーマンス

1. 下流アプリとの同期状態の検証

手動で同期を実行し、Prowlarrと下流アプリが正常に通信できているかを確認します。System > Tasksに移動し、Application Indexer Syncの横にある実行ボタンをクリックします。ターミナルから出力を確認してください。

# 同期中のアプリケーションログを確認
docker exec -it prowlarr tail -n 50 /config/logs/prowlarr.txt

[Info] Radarr: Updating indexersという出力があり、HTTP 401や403などのエラーなしにすべての定義が同期されていることを確認します。

2. レイテンシとトラッカー障害の監視

Prowlarrは、接続されているすべてのプロバイダーのパフォーマンスをアクティブに追跡します。これにより、自動ダウンロードに影響が出る前に障害の発生しているトラッカーを検知できます。

  • System > Status: HTTP 429レート制限、DNSルックアップのタイムアウト、連続した接続切断などが発生しているインデクサーに警告フラグを表示します。
  • System > Logs: APIクエリが失敗した際に、生のペイロードやデバッグ用データを表示します。
  • Historyタブ: クエリの応答時間（例：プライベートトラッカーの280msに対し、高負荷なパブリックサイトの2400msなど）を詳細に分析し、各インデクサーが返した取得候補の数を表示します。

3. Dockerコンテナのヘルスチェック自動化

Mono/.NETランタイムがフリーズした場合にDockerがコンテナを自動再起動できるよう、ネイティブのヘルスチェック設定を追加します。

    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9696/ping"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

docker compose up -dを再実行してヘルスチェックを適用します。これで、メディアスタック内の全コンテンツ検索における堅牢で信頼できる単一の情報源（Single Source of Truth）が整い、複数のダッシュボードを行き来する終わりのない手動メンテナンスから解放されます。

Share:
Tags: