Methods-to-configure-proxies-in-Docker
  • Published:
  • Last Updated:
  • Tools
  • 2 min read

容器技术解决了开发人员面临的许多难题,彻底改变了软件开发方式。它帮助交付能在各种系统和设备上可靠、一致运行的产品。Docker 又将容器技术提升到新高度,使容器的构建、管理和运行更加简便高效。Docker 还支持使用第三方代理,并提供了多种配置方式。为什么要将 Docker 与备用 IP 结合使用,哪种方式更适合你的场景,以及每一步该如何操作,本文将逐一说明。

为什么要在 Docker 中使用代理

答案是:确保互联网访问稳定、安全且可控。有时,使用代理只是为了能够访问网络。

Docker 需要访问网络来拉取镜像、安装软件包等。然而,许多企业网络会出于安全考虑管控或限制出站流量,这会妨碍开发工作。经批准的代理有时是访问网络并避免出现 “Connection timed out” 或 “Unable to access www.example.com“.

此外,某些网络访问需要身份验证。Docker 本身不提供这项支持,因此应使用外部代理。

运行中的应用也可能需要外部连接,例如容器需要访问云端 API、数据库或第三方服务。如果目标端点受防火墙保护,就需要通过代理访问。

使用代理还有其他好处。通过中间服务器路由流量可改善访问速度,并便于监控流量以进行日志记录、恶意软件防护、SSL 检查等。代理还能在不同服务器和机器之间保持网络配置一致,并隐藏 IP 地址、内部 DNS 请求和 NAT 等内部信息,从而提高安全性。

如何在 Docker 中配置代理

你可以在四个层面配置代理:Docker 守护进程,也就是 Docker Engine、Docker 客户端、容器和操作系统。每个层面的配置方法及影响范围都不同,各有优势,应按实际场景选择。下面将逐一说明各方法适合的用途及具体操作。

层面 1:配置 Docker 守护进程

在这一层配置的代理会控制镜像拉取和推送,以及对 Docker Hub 和私有镜像仓库的访问,也用于连接 Docker Swarm。

何时选择此选项:

  • 你需要所有镜像操作都通过代理进行;
  • docker pull 或 docker push 等命令失败;
  • 你必须将本机的所有流量通过企业代理路由;
  • 只有使用代理才能访问外部网络;
  • 使用 Docker Swarm 时。

这种方法稳定、可预测;如果使用 Docker Desktop,也可通过图形界面轻松配置。不过,在较旧版本(< 17.x)和少见配置中,这些设置可能影响所有容器,拖慢无需联网的容器。在现代版本中,守护进程代理不会自动传递给容器。

配置 Docker 守护进程代理有四种方法。

方法 1 – 使用 daemon.json

此方法仅适用于 Linux,也是该系统推荐的方式。在 daemon.json 文件中配置代理:


{
 "proxies": {
   "http-proxy": "http://proxy.example.com:3128",
   "https-proxy": "https://proxy.example.com:3129",
   "no-proxy": "*.test.example.com,.example.org,127.0.0.0/8"
 }
}

      
        
        
        
        
        
        

      

修改文件后,重启 Docker 以使更改生效:


sudo systemctl restart docker

      
        
      
方法 2 – 通过 systemd drop-in 文件

此方法同样仅适用于 Linux,适用于常规模式和 rootless 模式。

无论使用哪种模式,先创建系统目录:


sudo mkdir -p /etc/systemd/system/docker.service.d

      
        
      

然后创建名为 /etc/systemd/system/docker.service.d/http-proxy.conf 的文件,并在其中添加代理环境变量。


[Service]
Environment="HTTP_PROXY=http://proxy.example.com:3128"

      
        
        
      

如果使用 HTTPS 代理,请将变量改为 “HTTPS_PROXY”。你可以设置多个变量。然后保存文件并重启 Docker。


sudo systemctl daemon-reload
sudo systemctl restart docker

      
        
        
        
方法 3 – 为 dockerd 使用环境变量

Docker 守护进程会在启动前检查环境变量,不过这通常不是首选方法。


export HTTP_PROXY=...
dockerd

      
        
        
      
方法 4 – Docker Desktop

从技术角度看,Docker Desktop 依赖轻量级 Linux 虚拟机来运行和配置 Docker。你可能见过 Docker Desktop 仅适用于 Windows/macOS 的说法;它也可用于 Linux,但并不常见,而且管理的仍是 VM 内的守护进程,而非原生引擎。因此,这种方法更适合 Windows/macOS。按以下路径操作:

Docker Desktop > Settings > Resources > Proxies.

层面 2:配置 Docker 客户端(CLI)代理

Docker 客户端会通过代理发出请求,包括由 CLI 发起的 API 调用以及 docker login, docker pull, docker push.

何时选择此选项:

  • 如果你需要客户端通过代理进行身份验证;
  • 当公司对出站流量有限制时;
  • 当你不需要影响守护进程或容器时。

客户端配置快速简单,且无需重启守护进程。不过,它无法解决容器构建或运行时的访问问题,也无法解决守护进程的推送和拉取错误。

通常可使用 shell 环境变量配置 Docker 客户端。

在 Linux 和 macOS 上如下:


export HTTP_PROXY=http://PROXY:PORT

      
        
      


export HTTPS_PROXY=http://PROXY:PORT

      
        
      

在 Windows 上使用以下命令:


setx HTTP_PROXY http://PROXY:PORT

      
        
      

注意:在 Windows 上使用 CMD 可能会遇到问题,PowerShell 则可正常使用。

还有一种较少使用的方式:按单条命令配置。


HTTP_PROXY=http://PROXY docker login

      
        
      

层面 3:容器代理

采用此方法时,容器内的应用会使用代理。你可以为构建过程配置代理,也可以让容器在运行时使用代理。

何时选择此选项:

  • 容器需要外部连接;
  • 构建时无法运行包管理器;
  • 容器内的应用需要通过外部代理路由 API 请求。

该方法便于为每个容器单独配置,适合有些容器需要代理、另一些不需要的混合环境。它也能与操作系统和守护进程的配置明确分离。不过,每次构建和运行都要手动配置,不太适合大规模部署;代理凭据也可能泄露,存在安全风险。

方法 1 – 按构建配置代理

docker build \
 --build-arg HTTP_PROXY=http://PROXY:PORT \
 --build-arg HTTPS_PROXY=http://PROXY:PORT \
 -t myimage .

      
        
        
        
        
      
方法 2 – 使用 Dockerfile

Dockerfile 中的 ENV 环境变量会将设置写入镜像。这种方式存在安全风险,不建议用于构建。


ENV HTTP_PROXY=http://PROXY:PORT

      
        
      

ENV HTTPS_PROXY=http://PROXY:PORT

      
        
      
方法 3 – 按运行配置代理

docker run \
 -e HTTP_PROXY=http://PROXY:PORT \
 -e HTTPS_PROXY=http://PROXY:PORT \
 image

      
        
        
        
        
      
方法 4 – 选择 Docker Compose

这是安全且推荐的选项:


environment:
 HTTP_PROXY: http://PROXY:PORT
 HTTPS_PROXY: http://PROXY:PORT
 NO_PROXY: "localhost,127.0.0.1"

      
        
        
        
        
      

注意:Docker 官方文档中有两个不同概念都称为 CLI,容易造成混淆。一种是 Docker CLI 代理,影响客户端程序;另一种是 Docker CLI 标志(flags),它会将代理设置注入容器,影响的是容器而非客户端。不过,两者都通过命令行工具使用。

层面 4:操作系统代理

你可以将设备上的所有流量都设置为经过代理服务器。这会同时影响 Docker 守护进程和 Docker 客户端,有时还会影响容器及其他应用。

何时使用此选项:

  • 公司要求在系统层面使用代理;
  • 除 Docker 之外,还有许多应用也需要代理。

这种方法简单快捷:只需配置一次代理,设置便会对大多数组件和应用生效。但它并非 Docker 专用,也会增加调试难度。还需注意,容器很少会自动继承这些设置,因此仍可能需要单独配置。

这里提供了在各种操作系统中配置代理的分步教程,包括 macOSWindows.

此外,还可查阅 Docker 官方文档,了解各种方法和可用变量的更多细节。

Docker 守护进程代理配置

如何配置 Docker 客户端

如何调整 Docker Desktop 代理设置

Docker 有内部代理吗?

Docker 仅为镜像构建提供所谓的内部 HTTP(S) 代理,容易让人误以为不需要外部代理。

BuildKit 内部代理仅用于构建,可加快访问速度、消除 DNS 问题,并防止 DNS 设置泄露到构建过程中。但它无法建立安全的出站连接,不能替代外部代理。

常见配置问题及排查方法

Docker 的代理配置涉及多个层面,因此排查相关错误可能较为棘手。以下是五个最常见的问题及解决方法。

错误 1:docker pull/docker push 失败

如果通过代理拉取镜像时卡住、超时或连接被拒绝,说明 Docker 守护进程尚未识别代理配置。请在引擎层面配置代理。

错误 2:守护进程正常,却没有连接

如果 docker pull 可以正常工作,但容器无法运行 pip install 等依赖安装命令,并出现 Temporary failure resolving 一类错误,原因通常是现代 Docker 版本不会将守护进程代理自动传递到容器。请在 Dockerfile 或 Docker Compose 中配置容器层面的代理。

错误 3:NO_PROXY 变量不起作用

如果 Docker 仍忽略设置并尝试通过代理路由流量、容器之间无法通信,或无法访问镜像仓库,可能是语法不正确。请使用逗号分隔各项,填写域名时不要指定协议。

NO_PROXY=localhost,127.0.0.1,.corp.example.com,registry.internal

错误 4:代理凭据包含不受支持的符号

在这种情况下,Docker 可能无法启动,或无法通过代理路由流量。请对以下符号进行 URL 编码:@, #, %, :

编码后的形式如下:

Environment=”HTTP_PROXY=http://user:Pa%%23ss@proxy:8080″

错误 5:Docker 忽略 Desktop 代理设置

如果已在 Desktop 中设置代理,但构建失败且容器无法建立连接,可能需要改用其他配置方式。Desktop 会影响守护进程,但不会直接影响容器。请尝试配置容器层面的代理。

总结

Docker 与代理结合使用,可提升访问速度、安全性和部署效率。要充分发挥作用,既要选择合适的配置,也要选择来源合规的高质量代理。DataImpulse 提供超过 9000 万个来源合规的代理,并提供 24/7 人工支持,协助你完成开发工作。可发送邮件至 [email protected],或点击 “Try Now” 按钮开始使用。 点击 “Try now”,或通过 [email protected] 联系我们即可开始使用。

Share article: