Miért hagyja figyelmen kívül a docker pull a konténer proxybeállításait?

A képeket ténylegesen letöltő Docker-komponenst konfigurálja; a konténer proxyváltozói nem a démont vezérlik.

Ha a docker pull hibázik, a Docker-démont vagy a Docker Desktopot állítsa be. A kép letöltése azelőtt történik, hogy az alkalmazáskonténer elolvashatná a proxyváltozóit.

Natív Docker Engine

Egyesítse ezt a szakaszt a meglévő démon-proxykonfigurációval, cserélje le a dokumentációs végpontot, és tartsa meg a nem kapcsolódó beállításokat. Olyan nyilvános képek letöltési tesztjeihez, ahol nyilvános proxy megengedett, a HTTP-proxylista kínál jelölteket:

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

A démon kötőjeles kulcsai eltérnek a Docker-kliens ~/.docker/config.json fájljának camelCase kulcsaitól. A kliens proxyszakasza környezeti változókat ad az új konténereknek és buildfolyamatoknak; sem a démon letöltéseit, sem a már létező konténerek környezetét nem állítja be.

Végezze el a telepítéshez dokumentált démon-újraindítást, megtervezve a jelenlegi feladatokra gyakorolt hatását. A démon indulási környezetében is kaphat proxyváltozókat; egy későbbi terminálban végzett export nem frissít futó szolgáltatást.

Docker Desktop

Használja a Desktop proxybeállításait. A Docker dokumentációja szerint a Desktop figyelmen kívül hagyja a daemon.json proxybejegyzéseit, így a natív Engine példájának ismételt módosítása nem konfigurálja ennek a terméknek az útvonalát.

A megfelelő komponens frissítése után próbálja újra a kép letöltését. Derítse ki, hogy a registry elérése, a hitelesítés, az átirányítás vagy a rétegletöltés hibázott-e. Egy meglévő konténeren belüli működő HTTP-kérés csak az adott alkalmazás útvonalát ellenőrzi. Ne kerüljenek proxyhitelesítő adatok megosztott képernyőképekbe vagy commitolt fájlokba; a démonkonfiguráció és a konténerkörnyezet nem titoktároló.

Kapcsolódó cikkek