Immichではホストネットワークとブリッジネットワークのどちらを使うべきですか？

ほとんどのDockerベースのImmichデプロイでは、ユーザー定義ブリッジがよりすっきりしたデフォルトです。ホストネットワークは、普遍的なパフォーマンス向上策ではなく、特定の問題に対する対処法です。

Immichが主に必要とするのは、クライアントからサーバー、サーバーからデータベース、サーバーからRedis、機械学習、リバースプロキシへの信頼性の高い経路です。どちらのネットワークモードでも、これらを提供できます。選択する際は、実際の障害やアクセス要件を再現し、一度に1つのモードをテストし、観測と復旧が最も容易な構成を維持してください。

まずImmichが実際に必要とする経路を確認する

スタックをコンテナではなく接続として描いてみましょう。クライアントは公開またはローカルのImmichエンドポイントに接続し、プロキシはImmichサーバーに接続し、アプリケーションはPostgreSQLとRedisに接続し、サーバーは機械学習サービスに接続します。どの接続がDocker内部にとどまり、どの接続がホスト境界を越えるのかを確認してください。

ユーザー定義ブリッジでは、コンテナが独自のネットワーク名前空間を持ちながら、同じネットワーク上のサービスをサービス名で相互解決できます。Dockerネットワークモードについての概要は、この違いを理解するのに役立ちます。公開ポートはホストや外部クライアント向けに使用され、コンテナDNSはサービス間通信を処理します。

必要なすべての経路がすでにブリッジ上で機能しているなら、ホストネットワークは実証された問題を解決していません。ブリッジを維持し、サービス名、ネットワーク、公開ポートを記録しておけば、後でプロキシやComposeを変更した際に、既知のトポロジーと照合できます。

分離と安定したサービス名が重要ならユーザー定義ブリッジを優先する

ブリッジモードでは、すべてのコンテナポートをホスト上に公開することなく、明示的なアプリケーションネットワーク上でImmichのサービス同士を通信させられます。これは、リバースプロキシが同じネットワークを共有し、再作成後に変わる可能性のあるコンテナIPに依存せず、Immichのサービス名を直接指定できる場合に特に有用です。

ホストネットワークのトレードオフに関するホームラボの分析では、通常のホームラボのWebトラフィックにおいて、DockerのNATをなくしても意味のあるパフォーマンス向上になることはまれだと指摘されています。より重要な違いは、名前空間の分離、ポート公開、サービス同士の検出方法です。

ブリッジモードが設計上の問題になるのは、ネットワーク、DNS、ファイアウォール、プロキシの参加設定を修正しても、必要な経路を構成できない、または信頼性が保てない場合だけです。クライアントが「サーバーに接続できません」と報告したからといって、すぐにモードを切り替えないでください。まず、リクエストがDocker境界で停止していることを確認します。

ホストネットワークは、具体的で再現可能な要件がある場合だけ使用する

ホストモードでは、コンテナがホストのネットワーク名前空間に配置されるため、Dockerによるポート変換がなくなり、サービスはホストのネットワークコンテキストを使用します。これにより、特定のサービス検出や特殊なルーティングのケースが簡単になることがありますが、コンテナレベルのポート境界もなくなり、ホスト上のポート競合が発生しやすくなります。

ブリッジとホストネットワークの最新の比較では、パフォーマンス、分離、サービス公開、デバッグを軸に選択することが示されています。ホストモードのほうが本質的に信頼性が高いと考えるのではなく、これらの観点をImmichの経路に当てはめてください。

ホストモードで1つの症状が解消した場合は、テストを2回繰り返し、その理由を説明できるようにしてください。たとえば、同じホスト名、アカウント、プロキシ、クライアントがブリッジでは失敗し、ホストでは成功する一方で、アプリケーションログはそれ以外正常であることを確認します。結果を再現できない場合、モード変更によってDNSや古いネットワーク状態が一時的に隠れただけかもしれません。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

リバースプロキシは明示的で復旧可能な経路に保つ

リバースプロキシは、どちらのコンテナを再起動した後でも、安定した上流定義を通じてImmichに到達できる必要があります。ブリッジでは、手動でコピーしたコンテナIPではなく、共有ユーザー定義ネットワークとサービス名による上流指定を優先してください。ホストモードでは、競合がないことを確認しながら、意図したホストアドレスとポートをプロキシに指定します。

ZimaSpaceのホストとブリッジのテストパターンでは、同様の条件付きルールが使われています。サービス検出の簡便さはホストモードを選ぶ理由になり得ますが、分離と明示的なプロキシ統合はブリッジを支持します。Immichではプロトコルが異なるため、Plex固有のポート前提ではなく、判断方法を応用してください。

まずプロキシだけを再起動し、次にImmichだけを再起動し、その後スタック全体を再起動します。正常な設計なら、IPアドレスを編集しなくても、毎回同じローカルおよびリモート経路が復元されます。再作成後に手動で配線し直す必要があるトポロジーは、ホストネットワークかブリッジかにかかわらず、十分に安定していません。

同じ受け入れテストに、より少ないリスクで合格するモードを選ぶ

ローカルWebログイン、モバイルアプリの接続、小容量ファイルのアップロード、大容量ファイルのアップロード、リバースプロキシ経由のアクセス、サービス間のヘルスチェック、完全な再起動をテストします。レイテンシーと障害を記録しますが、どちらのモードもネットワーク上限を大きく下回っているなら、わずかなスループット差を過大評価しないでください。

すべての機能が通り、明示的な公開、コンテナDNS、分離のメリットを得られるなら、ブリッジを選びます。正しく構成されたブリッジでは必要な経路が再現可能な形で失敗し、ホストモードで解決する一方、ポート競合を起こさず、許容範囲を超えて公開範囲を広げない場合は、ホストを選びます。

両方のモードで同じように失敗するなら、ネットワークの切り替えを止めてください。原因はDNS、TLS、プロキシヘッダー、認証、ファイアウォール、ストレージ、またはアプリケーション自体にある可能性が高くなります。失敗したリクエストとログを保存し、より単純な既知の正常トポロジーに戻して、次の境界を診断してください。