为什么 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 请求只验证那个应用的路径。不要让代理凭据出现在共享截图和提交的文件中；守护进程配置与容器环境都不是秘密存储。

相关文章