新しいプロジェクト名でスタックを再作成すると、Compose のネットワークエイリアスが解決されなくなるのはなぜですか？
Composeのエイリアスは、サービスが別のプロジェクトスコープネットワークに参加した場合や、エイリアスがそのネットワークに設定されなくなった場合、再作成後に解決できなくなることがあります。
Dockerのエイリアスはグローバル名ではなく、ネットワーク単位で設定されます。スタックを新しいディレクトリ、明示的なプロジェクト名、Portainerのスタック名、またはComposeプロジェクト名で再作成すると、新しいデフォルトネットワークが作成され、別のアプリが古いネットワークに残ることがあります。サービスは正常で公開ポートから到達できても、呼び出し元と対象が同じネットワークを共有していない、またはリバースプロキシが別のネットワーク接続を選択したために、内部エイリアスだけが機能しない場合があります。
以前と現在のComposeプロジェクト名を比較する
以前と現在のプロジェクト名、作業ディレクトリ、スタック名、ネットワーク名、コンテナラベルを記録します。再作成後の呼び出し元サービスと対象サービスを比較してください。
Docker Composeはプロジェクト名を使用してリソースをグループ化し、名前を付けます。プロジェクト名の優先順位を確認すると、ディレクトリ名やデプロイ名を変更すると、以前のプロジェクトネットワークを再利用せず、新しいネットワークが作成される理由が分かります。
呼び出し元がoldproject_defaultに接続されたままで、対象がnewproject_defaultに参加している場合、以前のエイリアスには共有DNSスコープがありません。
実際に共有しているネットワーク上でエイリアスを確認する
両方のコンテナを調べ、接続されているすべてのネットワーク、エンドポイント、IPv4またはIPv6アドレス、エイリアスを一覧表示します。呼び出し元コンテナ内からDNSをテストしてください。
Compose仕様では、エイリアスはネットワーク単位の名前として定義されています。そのため、あるネットワークで宣言したエイリアスが別の接続先に自動的に存在することはありません。
エイリアスの宣言を、サービス同士が実際に共有しているネットワークへ移します。意図的なサービス検出の代わりにcontainer_nameへ依存しないでください。
外部ネットワーク名とデプロイ時の置換を確認する
論理上のComposeネットワークキーと、明示的な外部nameを比較します。デプロイ時に使用する環境変数の置換と、スタックUIの変数を確認してください。
Portainerのドキュメントでは、スタックで既存のDockerネットワークを使用できると説明されています。独立してデプロイしたスタック同士で名前解決する必要がある場合は、常に同じネットワークを選択する必要があります。
外部ネットワークを使用しても、すべてのスタックが同じ実際のネットワーク名を参照している場合に限り、プロジェクト接頭辞の変更を防げます。タイプミスがあると、サービスの公開ポートを変更せずに、別のネットワークが作成または選択されることがあります。
呼び出し元がキャッシュ済みアドレスではなくDocker DNSを使用していることを確認する
呼び出し元から新しい名前解決を実行し、リゾルバー設定を確認します。必要に応じて、DNSをキャッシュしているプロセスだけを再起動してください。名前解決の結果を、サービス名を直接指定した場合と比較します。
Linuxのネットワーク名前空間モデルはネットワークリソースを分離します。そのため、ホストでDNSが正常でも、呼び出し元コンテナが対象のDockerネットワークを共有しているとは限りません。
対象コンテナの現在のIPアドレスを/etc/hostsに追加しないでください。再作成されたコンテナには別のアドレスが割り当てられる可能性があり、別の依存先が古いまま残ってしまいます。
リバースプロキシが使用するネットワークを確認する
プロキシとアプリケーションのネットワーク接続、プロバイダーラベル、バックエンドへのルーティングに使用するネットワークを確認します。プロキシコンテナからエイリアスをテストしてください。
TraefikのDockerプロバイダーでは、バックエンド接続に使用するDockerネットワークを指定できます。
プロキシが複数のネットワークに接続されている場合、再作成後に自動選択の結果が変わることがあります。意図した共有ネットワークを明示的に設定し、実際のネットワーク名を一定に保ってください。
間違ったネットワークを削除せず、古いエンドポイントを整理する
古いネットワークと新しいネットワークに接続されているコンテナを一覧表示します。孤立したエンドポイント、停止中のコンテナ、古いプロジェクトネットワークに依存している稼働中のサービスを特定してください。
Red Hatのコンテナネットワーキングガイドでは、ユーザー定義コンテナネットワークへの接続は、アプリケーションファイルの内容ではなく、コンテナランタイムの状態の一部として説明されています。
古いネットワークを使用しているアクティブなスタックがないことを確認してから、ネットワークを削除してください。両方のネットワークを削除してすべてを一度に再作成すると、どの接続が誤っていたのかを示す証拠が失われます。
1つのサービスを再作成し、すべての呼び出し元からDNSを確認する
プロジェクト名または外部ネットワークを統一し、影響を受けたサービスだけを再作成します。その後、依存する各コンテナからサービス名とエイリアスをテストしてください。
ZimaSpaceのコンテナ実行時の依存関係に関する記事では、関連するルールとして、ホストレベルの接続テストではコンテナの名前空間とサービス検出経路を検証できないことを説明しています。
スタックの再作成と再起動後も、ハードコードされたIPアドレスを使わず、意図したすべての呼び出し元からエイリアスが現在のエンドポイントへ解決できれば、問題は解決しています。
よくある質問
Dockerのネットワークエイリアスはグローバルですか？
いいえ。エイリアスは設定されたネットワーク上にのみ存在し、そのネットワークを共有するコンテナだけが利用できます。
Composeフォルダー名を変更するとDNSが壊れることがありますか？
はい。フォルダー名はデフォルトのプロジェクト名に影響する場合があり、プロジェクト名または外部ネットワーク名を固定していないと、生成されるネットワーク名にも影響します。
DNSを安定させるためにcontainer_nameを使うべきですか？
通常は使用しません。安定したサービス名と明示的な共有ネットワークを使用すると、Composeのスケーリングを維持しながら、グローバル名の衝突を避けられます。
おすすめ商品
サポートとヒント
もっと読む
Dockerボリュームの復元でファイルの内容は再現されるのに、拡張属性が失われるのはなぜですか？
xattr のインベントリ、tar と Rsync のオプション、名前空間、保存先のサポート状況、権限、ラベル、アプリメタデータ、テストを網羅したボリューム復元の診断。
Composeファイルを変更した後も、実行中のコンテナが古いメモリ制限を維持するのはなぜですか？
ライブcgroup、再起動と再作成の違い、Composeのフィールド、ハードリミットとソフトリミット、親スコープ、スワップ、ランタイムヒープを網羅したメモリ制限の診断。
リバースプロキシを再起動すると、1つのセルフホストアプリですべてのセッションが無効になるのはなぜですか？
再起動の範囲、Cookieの所有権、シークレットのローテーション、キャッシュを利用したセッション、スティッキールーティング、認証ゲートウェイ、復旧を網羅したセッション喪失の診断。
