De ce docker pull ignoră setările proxy ale containerului

Configurează componenta Docker care descarcă efectiv imaginile, în loc să aștepți ca variabilele proxy ale containerului să controleze daemonul.

Dacă docker pull eșuează, configurează daemonul Docker sau Docker Desktop. Imaginea se descarcă înainte ca aplicația din container să poată citi variabilele proxy.

Docker Engine nativ

Combină această secțiune cu configurația proxy existentă a daemonului, înlocuind endpointul de documentație și păstrând setările fără legătură. Pentru teste cu imagini publice unde proxy-urile publice sunt permise, lista de proxy-uri HTTP oferă candidați:

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

Cheile daemonului cu cratime diferă de cheile camelCase din ~/.docker/config.json al clientului Docker. Secțiunea proxy a clientului furnizează variabile de mediu pentru containere noi și builduri; nu configurează descărcările daemonului sau mediile containerelor deja existente.

Aplică repornirea daemonului documentată pentru instalare și planifică efectul asupra sarcinilor actuale. Daemonul poate primi și variabile proxy în mediul de pornire; un export ulterior într-un terminal nu actualizează un serviciu care rulează.

Docker Desktop

Folosește setările proxy din Desktop. Docker documentează că Desktop ignoră intrările proxy din daemon.json, deci modificarea repetată a exemplului de Engine nativ nu configurează calea acestui produs.

Reîncearcă descărcarea imaginii după actualizarea componentei reale. Vezi dacă a eșuat accesul la registru, autentificarea, redirecționările sau descărcarea straturilor. O cerere HTTP reușită într-un container existent verifică doar ruta acelei aplicații. Nu include credențiale proxy în capturi partajate sau fișiere comise; configurația daemonului și mediul containerului nu sunt seifuri pentru secrete.

Articole similare