curl、.NET、コンテナ間のNO_PROXY互換性

チームは1つのバイパス文字列を共有の環境ファイルに置きます。curlは直接接続し、別のアプリケーションはプロキシを使い、コンテナはまた別の動作をします。共有ファイルは同じ文字を配布しました。しかし、共有のパーサーを1つ配布したわけではありません。

永続的な対象は方針です。どの宛先を、どの条件で直接にするのか。それを各プログラムが必要とする文字列とは切り離してください。

まず期待する経路を書き出します

簡単な成功例だけでなく、境界を含む代表的なアドレスを使います。

次に利用側を特定します。イメージを取得するデーモン、コンテナ内のプログラム、言語のHTTPライブラリ、対話型ブラウザはすべて別々の項目になり得ます。Dockerクライアントのプロキシ設定は、内部の各クライアントが同じ照合ルールを実装しなくても、コンテナの環境値を埋めることができます。

盲目的にコピーするのではなく翻訳します

実際の違いが文書化された例の1つは親ドメインの境界です。curlのドメイン除外は、指定されたドメインと一致する子を対象にします。.NETの環境ポリシーは、裸の名前と先頭ドット付きのサブドメイン形式を区別します。常に先頭ドットを付けるという普遍的な規則では、両方の方針を確実に表現できません。

IP範囲のサポートも利用側とそのバージョンに依存します。新しい単体のcurlがあるマシンでも、古いlibcurlにリンクされたアプリケーションや、まったく別のライブラリを使うクライアントを実行できます。OSのリリースは完全なクライアント一覧ではありません。

利用側ごとに、サポートされる設定インターフェースと意図する経路の最小の表現を記録します。短く明示的なホスト一覧は、誰も意味を説明できない巧妙なパターンより優れていることがあります。

設定の証拠と接続の証拠を分けて保持します

解析された設定やルーティング決定のAPIは、プログラムが何を選んだかを示せます。要求の結果は、その経路が利用可能だったかを示します。.NETでは、HttpClient.DefaultProxy.IsBypassed が、既定のプロキシが使用中の方針である場合に、その設定側のチェックを提供します。要求がタイムアウトしたという理由だけで、到達不能な直接サービスをバイパスパーサーの障害と診断しないでください。

クライアントやベースイメージを更新するときは、境界の宛先を残してください。それらは、ファイルに似た2つのドメイン項目がある理由をチーム全体が再発見する必要なく、将来の互換性の変化を可視化します。