In this Article
容器技术解决了开发人员面临的许多难题,彻底改变了软件开发方式。它帮助交付能在各种系统和设备上可靠、一致运行的产品。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 专用,也会增加调试难度。还需注意,容器很少会自动继承这些设置,因此仍可能需要单独配置。
这里提供了在各种操作系统中配置代理的分步教程,包括 macOS 和 Windows.
此外,还可查阅 Docker 官方文档,了解各种方法和可用变量的更多细节。
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] 联系我们即可开始使用。
