Waarom docker pull de proxy-instellingen van je container negeert

Configureer het Docker-onderdeel dat echt images ophaalt in plaats van te verwachten dat proxyvariabelen in een container de daemon regelen.

Mislukt docker pull, configureer dan de Docker-daemon of Docker Desktop. De image wordt gedownload voordat de applicatiecontainer zijn proxyvariabelen kan lezen.

Native Docker Engine

Voeg dit onderdeel samen met de bestaande proxyconfiguratie van de daemon. Vervang het documentatie-endpoint en behoud ongerelateerde instellingen. Voor tests met publieke images waarbij publieke proxy’s zijn toegestaan, biedt de HTTP-proxylijst kandidaten:

{
  "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"
  }
}

De daemonkeys met koppeltekens verschillen van de camelCase-keys in ~/.docker/config.json van de Docker-client. Het proxydeel van de client levert omgevingsvariabelen aan nieuwe containers en builds; het configureert geen daemondownloads of omgevingen van al bestaande containers.

Voer de voor de installatie gedocumenteerde daemonherstart uit en plan het effect op huidige werklasten. De daemon kan ook proxyvariabelen meekrijgen in zijn startomgeving; een latere export in een terminal werkt een draaiende service niet bij.

Docker Desktop

Gebruik de proxy-instellingen van Desktop. Docker documenteert dat Desktop proxyvermeldingen in daemon.json negeert. Het voorbeeld voor native Engine telkens veranderen configureert dus niet het pad van dit product.

Probeer de image opnieuw op te halen nadat je het juiste onderdeel hebt aangepast. Lees of registrytoegang, authenticatie, redirects of het downloaden van lagen is mislukt. Een werkend HTTP-verzoek in een bestaande container controleert alleen de route van die app. Houd proxy-inloggegevens uit gedeelde screenshots en gecommitte bestanden; daemonconfiguratie en containeromgeving zijn geen geheimenkluis.

Gerelateerde artikelen