有时候因为网络原因，比如公司NAT，或者其他的，需要使用代理。Docker的代理配置稍微复杂，因为有三种场景。但是基本原理是一样的，都是使用环境变量，比如linux的http_proxy。Dockerd代理执行dockerpull时，由守护进程dockerd执行。所以需要在dockerd环境中配置agent。而这个环境是由systemd控制的，所以其实就是systemd的配置。sudomkdir-p/etc/systemd/system/docker.service.dsudotouch/etc/systemd/system/docker.service.d/proxy.conf在这个proxy.conf文件中（可以是任何*.conf的形式），添加以下内容：[Service]Environment="HTTP_PROXY=http://proxy.example.com:8080/"Environment="HTTPS_PROXY=http://proxy.example.com:8080/"Environment="NO_PROXY=localhost,127.0.0.1,.example.com"其中proxy.example.com:8080应替换为可用的无密码代理。通常使用cntlm在本地搭建免密码代理，连接公司的代理。请参考《Linux下安装配置Cntlm 代理》。Containeragent在容器运行阶段，如果需要使用agent上网，需要配置~/.docker/config.json。以下配置只对Docker17.07及以上版本生效。{“代理”：{“默认”：{“httpProxy”：“http://proxy.example.com:8080”，“httpsProxy”：“http://proxy.example.com:8080”，“noProxy”:"localhost,127.0.0.1,.example.com"}}}这是用户级别的配置，除了proxy，dockerlogin等相关信息也会包含在内。并且还可以配置信息显示的格式、插件参数等。另外，容器的网络代理在运行时也可以直接通过-e注入http_proxy等环境变量。这两种方式适用于不同的场景。config.json非常方便。默认情况下，容器在所有配置更改生效后启动，适合个人开发环境。在CI/CD的自动构建环境，或者真正在线运行的环境中，这种方式是不适用的。最好用-e注入这个显式配置，减少对构建和部署环境的依赖。当然，在这些环境中，避免配置代理上网是很好的设计实践。dockerbuildagent虽然本质是启动一个容器，但是环境会略有不同，用户级别的配置会失效。构建时需要注入http_proxy等参数。dockerbuild.\--build-arg"HTTP_PROXY=http://proxy.example.com:8080/"\--build-arg"HTTPS_PROXY=http://proxy.example.com:8080/"\--build-arg"NO_PROXY=localhost,127.0.0.1,.example.com"\-tyour/image:tag注意：无论是dockerrun还是dockerbuild，默认都是网络隔离。如果代理使用localhost:3128之类的东西，它将无效。这种仅限本地的代理必须添加--networkhost才能正常工作。一般需要配置proxy的外网IP，proxy本身需要开启Gateway模式。重启生效代理配置完成后，重启当然可以生效，不重启也没关系。dockerbuildagent是在执行前设置的，所以修改后，下次执行会立即生效。Containeragent的修改也是立即生效的，但是只针对后面启动的Container，对于已经启动的Container无效。dockerdagent的修改比较特殊。它实际上改变了systemd的配置，所以需要重新加载systemd并重启dockerd才能生效。sudosystemctldaemon-reloadsudosystemctlrestartdocker
