Kial docker pull ignoras la prokurilajn agordojn de via ujo

Agordu la Docker-komponanton, kiu vere elŝutas bildojn, anstataŭ atendi ke la prokurilaj variabloj de la ujo regu la demonon.

Se docker pull malsukcesas, agordu la Docker-demonon aŭ Docker Desktop. La bildo estas elŝutata antaŭ ol la aplikaĵujo povas legi siajn prokurilajn variablojn.

Denaska Docker Engine

Kunigu ĉi tiun parton kun la ekzistanta prokurila agordo de la demono, anstataŭigu la dokumentan finpunkton kaj konservu senrilatajn agordojn. Por testoj de publikaj bildoj, kie publikaj prokuriloj estas permesitaj, la listo de HTTP-prokuriloj provizas kandidatojn:

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

La demonaj ŝlosiloj kun streketoj diferencas de la camelCase-ŝlosiloj en ~/.docker/config.json de la Docker-kliento. La klienta prokurila sekcio liveras medivariablojn por novaj ujoj kaj konstruoj; ĝi agordas nek demonajn elŝutojn nek la medion de jam ekzistantaj ujoj.

Apliku la dokumentitan demonrestartigon por la instalo, planante ĝian efikon al nunaj laborkvantoj. La demono povas ankaŭ ricevi prokurilajn variablojn en sia starta medio; posta export en terminalo ne ĝisdatigas jam funkciantan servon.

Docker Desktop

Uzu la prokurilajn agordojn de Desktop. Docker dokumentas, ke Desktop ignoras prokurilajn erojn en daemon.json, do ripetaj ŝanĝoj al la denaska Engine-ekzemplo ne agordas la vojon de tiu produkto.

Reprovu elŝuti la bildon post ĝisdatigo de la ĝusta komponanto. Legu ĉu malsukcesis registreja aliro, aŭtentikigo, alidirektoj aŭ tavolelŝuto. Funkcianta HTTP-peto en ekzistanta ujo kontrolas nur la itineron de tiu aplikaĵo. Ne inkluzivu prokurilajn akreditaĵojn en komunaj ekrankopioj aŭ enmetitaj dosieroj; demona agordo kaj uja medio ne estas sekretdeponejoj.

Rilataj artikoloj