【docker】Dockerfile 中使用宿主机代理的方式

在Dockerfile中配置代理主要有这几种方式，让我系统地整理一下：

1. 构建参数方式（BUILD ARG）

# 方式1：在Dockerfile顶部定义
ARG HTTP_PROXY=http://proxy:7890
ARG HTTPS_PROXY=http://proxy:7890

# 方式2：在构建命令中传入
docker build --build-arg HTTP_PROXY=http://proxy:7890 .

2. 环境变量方式（ENV）

# Dockerfile中永久设置
ENV http_proxy=http://proxy:7890
ENV https_proxy=http://proxy:7890

# 或者在RUN命令中临时设置
RUN export http_proxy=http://proxy:7890 && \
    export https_proxy=http://proxy:7890 && \
    curl example.com

3. 特定工具的代理设置

# wget专用
RUN wget --proxy-user=user --proxy-password=password \
         --proxy=on http://example.com

# curl专用
RUN curl -x http://proxy:7890 http://example.com

# git专用
RUN git config --global http.proxy http://proxy:7890

4. Docker构建时的网络设置

buildx_cmd = [
    'docker',
    'buildx',
    'build',
    '--network=host',  # 使用主机网络
    '--add-host=host.docker.internal:host-gateway'  # 允许访问主机
]

Wait… 让我想想这些方式的使用场景…

这些方式各有优劣：

proxy_methods = {
    "BUILD ARG": {
        "优点": "灵活性高，可在构建时动态指定",
        "缺点": "需要在构建命令中指定，或在Dockerfile中设默认值",
        "适用": "需要在构建时动态改变代理配置的场景"
    },
    "ENV": {
        "优点": "持久生效，影响所有网络操作",
        "缺点": "会被打入最终镜像，可能造成信息泄露",
        "适用": "需要在整个容器生命周期都使用代理的场景"
    },
    "工具专用配置": {
        "优点": "精确控制特定工具的代理行为",
        "缺点": "配置分散，需要针对每个工具单独设置",
        "适用": "对特定工具有特殊代理需求的场景"
    },
    "网络设置": {
        "优点": "直接使用主机网络，简化配置",
        "缺点": "可能带来安全隐患",
        "适用": "开发环境或信任主机网络的场景"
    }
}

Let me think… 在实际项目中，这些方式经常是混合使用的。比如：

# 示例：混合使用多种代理配置方式
ARG HTTP_PROXY
ENV http_proxy=$HTTP_PROXY

RUN export https_proxy=$HTTP_PROXY && \
    curl -x $HTTP_PROXY https://example.com && \
    wget --proxy=on https://example.com

在实际使用中更倾向于在RUN命令中直接设置环境变量的方式，这种方式的好处是：

1. 代理设置只影响特定的构建步骤
2. 不会将代理信息保留在最终镜像中
3. 可以针对不同的构建步骤使用不同的代理配置