Per què docker pull ignora el proxy del contenidor

Configura el component de Docker que realment baixa les imatges en lloc d’esperar que les variables proxy del contenidor controlin el dimoni.

Si docker pull falla, configura el dimoni de Docker o Docker Desktop. La imatge es baixa abans que el contenidor de l’aplicació pugui llegir les seves variables proxy.

Docker Engine natiu

Combina aquesta secció amb la configuració proxy existent del dimoni, substitueix el punt final de documentació i conserva els ajustos aliens. Per a proves d’imatges públiques on es permetin proxies públics, la llista de proxies HTTP ofereix candidats:

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

Les claus del dimoni amb guionets difereixen de les claus camelCase de ~/.docker/config.json del client Docker. La secció proxy del client aporta variables d’entorn als contenidors nous i les construccions; no configura les baixades del dimoni ni els entorns de contenidors ja existents.

Fes el reinici del dimoni documentat per a la instal·lació, preveient-ne l’efecte en les càrregues actuals. El dimoni també pot rebre variables proxy a l’entorn d’arrencada; un export posterior en un terminal no actualitza un servei en execució.

Docker Desktop

Fes servir les opcions proxy de Desktop. Docker documenta que Desktop ignora les entrades proxy de daemon.json; per tant, canviar repetidament l’exemple d’Engine natiu no configura el camí d’aquest producte.

Torna a provar la baixada després d’actualitzar el component correcte. Identifica si ha fallat l’accés al registre, l’autenticació, les redireccions o la baixada de capes. Una petició HTTP correcta dins d’un contenidor existent només comprova el camí d’aquella aplicació. No posis credencials proxy en captures compartides ni fitxers confirmats; la configuració del dimoni i l’entorn del contenidor no són magatzems de secrets.

Articles relacionats