如何在代理下使用"docker login"?

6

我正在尝试运行docker login,但是我遇到了以下错误:

Error response from daemon: Get "https://[removed_id_for_stackoverflow].dkr.ecr.us-east-1.amazonaws.com/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

我在我的~/.bash.rc文件中有以下内容:

export HTTP_PROXY="http://192.168.1.1:8080"
export HTTPS_PROXY="http://192.168.1.1:8080"
export https_proxy="http://192.168.1.1:8080"
export https_proxy="http://192.168.1.1:8080"
export ftp_proxy="http://192.168.1.1:8080"
export no_proxy="localhost,127.0.0.1,::1"

如果我运行curl https://www.google.com,那么就会得到一个有效的响应,证实这些设置是有效的。如果我删除这些环境变量,那么我的curl命令就无法工作,因此我非常确定从环境变量的角度来看它已经正确配置了。
根据Docker Hub登录代理,你只需要在运行docker login时将代理选项传递到命令行即可;然而,我已经尝试过这个方法,结果还是一样。请见下面的例子:
root@my-host:~/.docker# HTTPS_PROXY=http://192.168.1.1:8080 aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin $(aws sts get-caller-identity --output text --query 'Account').dkr.ecr.us-east-1.amazonaws.com >/dev/null
Error response from daemon: Get "https://[removed_for_stack_overflow].dkr.ecr.us-east-1.amazonaws.com/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

我尝试将代理设置更改为出现在docker login之前而不是aws,尝试使用HTTP_PROXY而不是HTTPS_PROXY,但仍然没有运气。似乎无论以哪种顺序指定代理选项都无济于事。

我还有一个名为〜/ .docker / config.json 的文件,其中包含以下代理信息:

{
 "proxies":
 {
   "default":
   {
     "httpProxy": "http://192.168.1.1:8080",
     "httpsProxy": "http://192.168.1.1:8080"
   }
 }
}

即使设置了这个选项,docker login 似乎仍然无法正常工作,并提供相同的结果。


http://pahlevanzadeh.net/docker-pull-%d9%88-systemd-%d9%85%d8%b4%da%a9%d9%84-%da%a9%d8%b4%d9%88%d8%b1%d9%87%d8%a7%db%8c%db%8c-%d9%85%d8%ab%d9%84-%d8%a7%db%8c%d8%b1%d8%a7%d9%86/ - PersianGulf
2个回答

11
正确的配置 Docker 守护进程的代理方式已经记录在此处,https://docs.docker.com/config/daemon/systemd/#httphttps-proxy。以下是一些相关内容的提取:
  1. Create a systemd drop-in directory for the docker service:

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

  2. Create a file named /etc/systemd/system/docker.service.d/http-proxy.conf that adds the HTTP_PROXY/HTTPS_PROXY environment variable:

    Config example:

    [Service]
    Environment="HTTP_PROXY=http://proxy.example.com:80"
    Environment="HTTPS_PROXY=https://proxy.example.com:443"
    Environment="NO_PROXY=localhost,127.0.0.1,docker-registry.example.com,.corp"
    
  3. Flush changes and restart Docker

    sudo systemctl daemon-reload
    sudo systemctl restart docker
    
  4. Verify that the configuration has been loaded and matches the changes you made, for example:

    sudo systemctl show --property=Environment docker


尝试过了,但没有成功。守护进程代理设置已按照您的第4步正确设置和配置,但“docker login”命令仍然超时,并且似乎没有使用代理。我认为问题不在于Docker守护程序。 - LewlSauce
更改为错误的代理,例如 http://proxy.example.com:80,应该会出现以下错误:Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: dial tcp: lookup proxy.example.com: no such host,这只是为了证明您已经正确设置了一个虚假代理,正如您从日志中看到的,它在第一阶段尝试连接代理。那么超时是什么意思?这里有任何错误吗?在您的计算机之前有任何硬件防火墙吗?是否有任何iptables阻止输出连接? - atline
只是将代理设置为随机字符以查看是否会出现一些DNS解析错误,但使用“docker login”命令仍然没有运气。实际上,它不再超时,而是挂起,但我应该在配置代理之前就提到了这一点。我可以使用其他命令,如“cURL”等,没有任何问题,因此我有一种感觉代理设置是正确的,但也许“docker login”不喜欢使用代理?没有IP表,防火墙等。 - LewlSauce
好奇怪。重复相同的步骤后,现在似乎正常工作了。非常感谢您的帮助。不确定为什么第一次会出问题。 - LewlSauce

0
atline的方法是正确的。 但是我在使用带有用户名/密码的代理环境时没有成功,无论我尝试了什么。
最后,以下步骤解决了问题:
  • 按照atline的方法配置代理,但是不要包括用户名/密码
  • 在你的shell/system中配置代理(包括用户名/密码),这样你就可以使用curl命令,比如curl stackoverflow.com通过代理访问
  • 然后启动你的docker工作负载(在我的情况下是docker-compose up
  • 连接突然变得可行
在长时间的工作负载期间,可能需要在单独的终端中执行curl命令的技巧(也许你可以编写脚本并定期触发curl命令)。
似乎代理会缓存登录信息一段时间。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接