Docker ベースイメージの取得: ビルダーのプロキシとビルド引数の違い
ビルドステップに渡したプロキシ引数は、ビルダーが行うすべてのレジストリ要求を設定するわけではありません。ベースイメージを解決するビルダーを特定してください。
Dockerfile のパッケージ取得ステップが動く前に、FROM の解決中にビルドが失敗することがあります。ビルダーのレジストリクライアントは、そのベースイメージを取得するための独自の経路を必要とします。
| 操作 | 経路を必要とするコンポーネント |
|---|---|
| ベースイメージの解決と取得 | ビルダーのレジストリクライアント |
| RUN 中のダウンロード | ビルドステップを実行するプロセス |
| 実行時の API 呼び出し | 実行中のアプリケーション |
ビルダーを特定する
既定の Docker ドライバーはデーモンを中心にしています。他の Buildx ドライバーは、専用の BuildKit コンテナ、Kubernetes、またはリモートサービスを利用できます。選択したドライバーが対応するプロキシ方式を、そのワーカーが動作する場所で設定してください。
ノート PC のループバックプロキシはリモートワーカーから自動的に到達できるわけではなく、ローカルのデーモンを編集してもそのリモートビルダーは再設定されません。
FROM の前の ARG はイメージ参照の選択に役立ちます。しかしそれによってレジストリクライアントのネットワーク経路が設定されるわけではありません。後からパッケージ設定を書き込んだり証明書をインストールしたりする RUN コマンドは、この以前の要求を修復できません。
信頼、アカウント、キャッシュされたデータ
承認済みの CA マテリアルは、最初のレジストリ接続を検証するコンポーネントから利用できる必要があります。レジストリの資格情報とプロキシの資格情報は別々の当事者を認可します。レジストリへのログインでプロキシの 407 に応答することはできません。
キャッシュされたイメージデータを再利用するワーカーは、新しいワーカーと同じネットワーク要求を繰り返さない場合があります。実際に記録された操作を比較してください。ベースイメージへのアクセスが意図した経路で機能したら、以降のビルドステップのダウンロードはその次の境界で診断してください。