Open tesharp opened 5 years ago
why this is not get any attentation ?
Why are you using a proxy instead of a mirror configuration?
Also note that your strace on "docker pull" is tracing the client, but the actual pull (including dns resolution) would happen on the daemon process.
In my lab env, I have set registry-mirrors
in the /etc/docker/daemon.json
, but pull fail with dns query and cannot continue pull image from registry mirror.
# docker pull bitnami/metallb-controller
Using default tag: latest
Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:41737->[::1]:53: read: connection refused
# cat /etc/docker/daemon.json
{
"registry-mirrors": ["https://mirror.myinternal.repo"]
}
Expected behavior
When defining proxy for docker we expect it to use proxy for all commands. It should not use any longer time then normally.
Actual behavior
when pulling against private repo it takes a very long time because it first tries to resolve the dns for private repo against dns servers defined on machine. It cannot resolve the dns and uses about 1-2 minute to try resolving it before just using proxy as it should. So every pull etc takes 1-2 minute to just start.
Steps to reproduce the behavior
docker pull testbug.azurecr.io/alpine:latest
, it will take a very long time to just startstrace -t docker pull testbug.azurecr.io/alpine:latest
it should be possible to see that it tries dns lookup against internal dns servers for testbug.azurecr.io.A hack to fix is to define testbug.azurecr.io in
/etc/hosts
with address 127.0.0.1. It will then manage to "resolve" the address and continue fast, still using proxy to actually pull the image. So doesn't matter what it is resolved to because it still uses proxy for pulling. Shouldn't be a need to do dns lookup at all.