企業プロキシが Compose サービス名を解決しようとする理由

アプリケーションは企業プロキシ経由でインターネットに接続しますが、http://catalog:8080/ は失敗し、プロキシは「catalog」を解決できません。そのリクエストは Docker の内部 DNS を一度も使っていない可能性があります。

HTTP クライアントは、直接接続を行う前にプロキシを選択することがあります。その場合、外部プロキシは Compose ネットワーク内でしか意味を持たない名前を受け取ります。

1. リクエストにはホスト名を使う。 Compose サービスは適切なネットワーク上でサービス名によって検出できます。変化しうるコンテナ IP をハードコードするのではなく、利用側クライアントが対応するバイパス設定に catalog を追加してください。
2. 既存の例外を保つ。 環境を認識するクライアントでは、該当するエントリを組織のリストに統合します:

NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

イメージ内の実際のライブラリまたは実行ファイルについて、大文字小文字の扱い、バージョン、照合の文法を確認してください。万能な NO_PROXY パーサーは存在しません。小さなイメージ内の wget という名前のプログラムが GNU Wget と同じように動作する必要はありません。

リクエストが直接ルーティングを選んだら、呼び出し側とサービスの共有ネットワーク、待ち受けているサービス、コンテナポートを確認してください。公開されたホストポートは別のエンドポイントです。バイパスは欠けているネットワーク接続を追加できません。ネットワークを作り直しても外部プロキシにプライベートな Compose 名を教えることはできないのと同じです。

意図した分離を保ってください。内部リクエストは内部経路を使い、外部リクエストは承認済みプロキシを使います。プロキシを全体で無効にすると、この一つの障害を隠す一方で、次の外部リクエストに必要な経路を失います。