問題描述
在使用 docker build 打包鏡像時，遇到了需要使用代理訪問網絡的需求。使用如下的 Dockerfile 來模擬這個場景：
FROM golang:1.12
RUN curl www.google.com --max-time 3
國內一般網絡環境下，curl www.google.com 是無法正常返回的，加入 --max-time 讓 curl 的耗時不要太長。
配置 http_proxy 變量
首先需要在環境變量中設置 http_proxy 和 https_proxy，使得訪問網絡的命令（這裏使用 curl 來代表）能夠通過環境變量中配置的代理服務器訪問 www.google.com。
docker build 命令雖然是在 docker 所在的宿主機上執行的，看上去像是直接使用了宿主機的網絡環境，但實際上 docker build 也是啓動了一個 container 進行構建，所以在構建過程中的所有命令都是在 container 中執行的，http_proxy 和 https_proxy 的配置也應該是在 container 中進行的。可以使用 ENV 來配置 container 中的環境變量。
代理服務器啓動在宿主機的 1087 端口上，修改 dockerfile 文件：
FROM golang:1.12
ENV http_proxy "http://127.0.0.1:1087"
ENV HTTP_PROXY "http://127.0.0.1:1087"
ENV https_proxy "http://127.0.0.1:1087"
ENV HTTPS_PROXY "http://127.0.0.1:1087"
RUN curl www.google.com --max-time 3
重新執行 docker build 會發現 curl 依舊無法訪問 www.google.com，從報錯信息上可以看到 127.0.0.1 上的 1087 端口上並沒有服務。
訪問宿主機
由於 container 默認是橋接網絡，宿主機和 container 是平級的，被放在了一個虛擬的網段裏。訪問宿主機上的代理服務器，對於 container 來說實際上是訪問另一臺機器上的服務器，127.0.0.1 指向的是 container 本身。在 docker 默認的橋接網絡中，宿主機的 IP 一般是 172.17.0.1（Linux），或者 192.168.65.1（MacOS），可以將 http_proxy 中的 IP 換成 172.17.0.1/192.168.65.1，來實現通過宿主的代理服務器訪問網絡，修改 dockerfile：
FROM golang:1.12
ENV http_proxy "http://172.17.0.1:1087"
ENV HTTP_PROXY "http://172.17.0.1:1087"
ENV https_proxy "http://172.17.0.1:1087"
ENV HTTPS_PROXY "http://172.17.0.1:1087"
RUN curl www.google.com --max-time 3
雖然使用這種方式可以達到目的，但是如果編譯環境變了或者代理服務器的配置變了，哪怕只是操作系統從 Linux 變成了 MacOS，都得修改 dockerfile，顯然不夠解耦，也不方便。
配置網絡模式
docker 中還有一種 host 網絡模式，就是讓 container 使用宿主機的網絡，相當於 container 在網絡層面和宿主機不做隔離，使用這種網絡模式執行 docker build，就不需要在 dockerfile 中添加 http_proxy 環境變量，container 可以直接讀取宿主上的環境變量。
首先在宿主上導入 http_proxy 環境變量：
export http_proxy="http://127.0.0.1:1087";
export HTTP_PROXY="http://127.0.0.1:1087";
export https_proxy="http://127.0.0.1:1087";
export HTTPS_PROXY="http://127.0.0.1:1087"
接下來將 dockerfile 簡化：
FROM golang:1.12
RUN curl www.google.com --max-time 3
重新執行，curl 就可以像在宿主上直接執行一樣，通過代理訪問 www.google.com 了。