Varför docker pull ignorerar containerns proxyinställningar

Konfigurera den Docker-komponent som faktiskt hämtar images i stället för att vänta dig att containerns proxyvariabler styr daemonen.

Om docker pull misslyckas ska du konfigurera Docker-daemonen eller Docker Desktop. Imagen laddas ned innan applikationscontainern kan läsa sina proxyvariabler.

Fristående Docker Engine

Slå samman avsnittet med den befintliga proxykonfigurationen för daemonen, byt dokumentationsendpointen och bevara orelaterade inställningar. För tester med publika images där publika proxyer är tillåtna ger HTTP-proxylistan kandidater:

{
  "proxies": {
    "http-proxy": "http://203.0.113.10:8080",
    "https-proxy": "http://203.0.113.10:8080",
    "no-proxy": "localhost,127.0.0.1,registry.example.internal"
  }
}

Daemonnycklarna med bindestreck skiljer sig från camelCase-nycklarna i Docker-klientens ~/.docker/config.json. Klientens proxyavsnitt ger miljövariabler till nya containrar och byggen; det konfigurerar varken daemonens nedladdningar eller miljön i befintliga containrar.

Gör den daemonomstart som dokumenteras för installationen och planera påverkan på aktuella arbetslaster. Daemonen kan också få proxyvariabler i sin startmiljö; en export i en senare terminal uppdaterar inte en tjänst som redan körs.

Docker Desktop

Använd Desktops proxyinställningar. Docker dokumenterar att Desktop ignorerar proxyposter i daemon.json, så att ändra exemplet för native Engine om och om igen kan inte konfigurera den här produktens väg.

Försök hämta imagen igen efter att rätt komponent uppdaterats. Läs om felet gäller registeråtkomst, autentisering, omdirigeringar eller nedladdning av lager. En fungerande HTTP-förfrågan i en befintlig container kontrollerar bara den applikationens väg. Håll proxyuppgifter borta från delade skärmbilder och incheckade filer; daemonkonfiguration och containermiljö är inga hemlighetsvalv.

Relaterade artiklar