docker pull がコンテナのプロキシ設定を使わない理由

コンテナのプロキシ変数でデーモンを制御しようとせず、実際にイメージを取得するDockerコンポーネントを設定します。

docker pull が失敗したら、DockerデーモンかDocker Desktopを設定します。イメージのダウンロードは、アプリケーションコンテナが自身のプロキシ変数を読み取れるようになる前に行われます。

ネイティブの Docker Engine

この部分を既存のデーモンのプロキシ設定に組み込み、ドキュメント用エンドポイントを置き換え、無関係な設定は残してください。公開プロキシを使った公開イメージの取得テストが許可されている場合、HTTPプロキシリストから候補を選べます。

{
  "proxies": {
    "http-proxy": "http://203.0.113.10:8080",
    "https-proxy": "http://203.0.113.10:8080",
    "no-proxy": "localhost,127.0.0.1,registry.example.internal"
  }
}

デーモンのハイフン付きキーは、Dockerクライアントの ~/.docker/config.json にあるcamelCaseのキーとは異なります。クライアントのプロキシ設定は、新しいコンテナやビルド向けに環境変数を供給します。デーモンのダウンロードも、既存コンテナの環境も設定しません。

そのインストール形態の文書に従ってデーモンを再起動し、現在の処理への影響を事前に考慮してください。デーモンの起動環境にプロキシ変数を渡す方法もあります。後から端末でexportしても、動作中のサービスは更新されません。

Docker Desktop

Desktopのプロキシ設定を使います。Dockerの文書では、Desktopは daemon.json のプロキシ項目を無視すると説明されています。そのため、ネイティブEngineの例を繰り返し変更しても、この製品の経路は設定できません。

実際の担当コンポーネントを更新した後に、イメージ取得を再試行します。レジストリへのアクセス、認証、リダイレクト、レイヤーのダウンロードのどこで失敗したかを読み取ってください。既存コンテナ内でHTTPリクエストが通っても、そのアプリの経路を確認しただけです。共有スクリーンショットやコミットするファイルにプロキシ認証情報を含めないでください。デーモン設定やコンテナ環境は秘密情報の保管庫ではありません。

関連記事