データベースを再構築せずに、コンテナの公開ポートを変更できますか？
はい、データベースが同じ検証済みの永続ストレージに保存されている場合は、データベースを再構築せずにコンテナの公開ポートを変更できます。
ホームNASやDockerホストでは、通常、外部から見えるポートは一時的なアプリケーションコンテナに属し、レコード、アカウント、設定は名前付きボリューム、バインドマウント、または別のデータベースサービスに保存されます。そのため安全な変更方法は、デプロイ定義と永続パスを維持し、ホスト側の公開ルールだけを変更して対象のアプリサービスを再作成し、その後、古いポートを参照しているプロキシ、ブックマーク、コールバック、ファイアウォールルール、ヘルスチェックをすべて確認することです。
公開ホストポートとコンテナのリスニングポートを分けて考える
変更前に、現在のマッピングを2つの異なるエンドポイントとして書き出してください。8080:80では、クライアントはDockerホストのポート8080に接続し、アプリケーションはコンテナ内のポート80で引き続き待ち受けます。左側を変更しても、アプリケーションプロセスやデータベース接続は自動的には変わりません。
Dockerコミュニティのトラブルシューティング事例では、ホスト側のマッピングと内部のリスニングポートは別物であり、移行先ポートで内部で何も待ち受けていない場合は、新しい公開ポートが機能しないことが説明されています。
実行中のコンテナの公開ポートとリスニングソケットを確認し、コンテナ内部または同じネットワークから内部エンドポイントをテストしてください。アプリケーション自体を移行する必要がない限り、内部ポートは変更しないでください。この最初のテストにより、単純なホストポート変更が不要なアプリケーション再設定に発展するのを防げます。
サービスを再作成する前に現在のデータベースパスを保護する
Composeファイル、イメージタグまたはダイジェスト、環境ファイル、名前付きボリューム、バインドマウント、ネットワーク名、シークレット、データベースのホスト名を記録してください。目的は、Dockerがアプリケーションコンテナを置き換える前に、どのオブジェクトが永続状態を保持しているかを確認することです。
ポート公開の変更には新しいコンテナ設定が必要ですが、新しいイメージのビルドや新しいデータベースは必要ありません。実用的なDockerの回答では、ポート設定の変更時に必要なのはイメージの再ビルドではなく、コンテナの再作成であることが区別されています。
重要なサービスであれば、現在のアプリケーションと整合したデータベースのバックアップまたはスナップショットを取得し、データベースのパスがコンテナの書き込みレイヤー内にないことを確認してください。マウント一覧が不明確な場合、ボリューム名が変わっている場合、または現在のアプリが予期しない空のデータベースを使用しているように見える場合は、作業を中止してください。
ホスト側のマッピングだけを変更してアプリサービスを再作成する
アプリケーションサービスのマッピングを8080:80から8081:80のように変更します。別の検証済みの要件がない限り、イメージ、内部ポート、ボリューム、データベースURL、サービス名、ネットワーク、ユーザーマッピングは変更しないでください。
Composeのポート構文はホストからコンテナへの順序で解釈されるため、ホスト側を変更しても、プロセスは既存の内部ポートで待ち受け続けます。Dockerフォーラムの例では、左側がホストポートであり、右側はアプリケーションのリスニングポートと一致させる必要がある理由が説明されています。
更新した定義を使って、アプリケーションサービスだけを再作成してください。ボリュームを削除するスタックコマンドは使用せず、データベースを再初期化せず、イメージ自体を変更した場合を除いて--buildも追加しないでください。再作成後は、マイグレーションやバックグラウンドジョブを実行させる前に、実際に適用されたマウントとポートマッピングを確認してください。
古いポートに依存するすべてのクライアント経路を更新する
公開ポートを利用するのはブラウザのブックマークだけではありません。リバースプロキシ、ルーターのポート転送、ローカルファイアウォール、監視プローブ、モバイルアプリ、Webhookの送信先、OAuthコールバック、CORSの許可リスト、生成された公開URLなども、以前のエンドポイントを参照している可能性があります。
セルフホスト型アプリケーションの中には、ループバックリクエストを送信したり、設定された公開アドレスからコールバックURLを生成したりするものがあります。WordPressコンテナのディスカッションでは、データベースが正常なままでも、外部マッピングの変更によってポートを考慮したループバック動作が発生する可能性が示されています。
Composeプロジェクト、プロキシ設定、環境ファイル、アプリケーション設定で古いポートを検索してください。ホストエンドポイントを実際に使用しているレイヤーだけを更新します。通常、内部コンテナは新しく公開したホストポートではなく、サービス名と内部ポートを使い続けるべきです。
データベースはプライベートなコンテナパスに置いたままにする
Webアプリケーションのホストポートが変わったからといって、データベースのポートを変更したり公開したりしないでください。同じスタック内のコンテナだけが使用するデータベースは、ホスト側で公開しなくても、サービス名と内部ポートで引き続きアクセスできます。
アプリの公開エンドポイントとデータベース接続を混同すると、2つ目の障害が発生する可能性があります。データベースをプライベートなDockerネットワーク上に置く想定なのに、アプリケーションがNASのアドレスとホストポートを使用するよう変更される場合があるためです。この変更は、ブラウザからWebサービスへアクセスしやすくすることなく、ファイアウォール、NAT、認証に関する要因を増やします。
再作成したアプリケーションコンテナから、データベースのサービス名を解決し、内部TCPポートを開いて認証し、安全な読み取り処理を実行してください。その経路が変わっていなければ、変更しないでください。データベースのテストに失敗した場合は、別のネットワークまたは認証情報の問題を調査する前に、元のアプリケーション定義へ戻してください。
永続データに触れずに新しいポートを確認する
まず新しいホストポートに直接接続してテストし、次に通常のホスト名またはリバースプロキシ経由のルートをテストしてください。ログイン、レコードの読み取り、元に戻せる書き込みを1回、アップロード、スケジュールジョブ、連携機能、そして計画的なコンテナ再起動を確認します。
新しいブラウザエンドポイントは機能するのにDockerがサービスをunhealthyと報告し続ける場合は、ZimaSpaceの実際のアプリケーション経路に合わせたヘルスチェックガイドを次に確認してください。
新しい公開ポートが再作成と再起動後も維持され、プロキシとクライアントが古いエンドポイントを使用せず、アプリケーションが同じ永続データベースへ再接続し、データベースのバックアップも利用可能であることを確認できて、初めて変更は完了です。アプリケーションが新しい空の状態で起動したり、予期しないマイグレーションを開始したりする場合は、ポートマッピングを元に戻してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
