Kāpēc docker pull ignorē konteinera starpniekservera iestatījumus

Iestatiet Docker komponentu, kas patiešām lejupielādē attēlus, nevis gaidiet, ka konteinera starpniekservera mainīgie vadīs dēmonu.

Ja docker pull neizdodas, iestatiet Docker dēmonu vai Docker Desktop. Attēls tiek lejupielādēts, pirms lietotnes konteiners var nolasīt savus starpniekservera mainīgos.

Tieši instalēts Docker Engine

Apvienojiet šo sadaļu ar esošo dēmona starpniekservera konfigurāciju, aizstājiet dokumentācijas galapunktu un saglabājiet nesaistītos iestatījumus. Publisko attēlu testiem, kur publiski starpniekserveri ir atļauti, HTTP starpniekserveru saraksts piedāvā kandidātus:

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

Dēmona atslēgas ar defisēm atšķiras no camelCase atslēgām Docker klienta ~/.docker/config.json failā. Klienta starpniekservera sadaļa dod vides mainīgos jauniem konteineriem un būvēšanai; tā neiestata dēmona lejupielādes vai jau esošo konteineru vidi.

Veiciet instalācijai dokumentēto dēmona restartu un plānojiet ietekmi uz pašreizējiem darbiem. Dēmons var saņemt starpniekservera mainīgos arī startēšanas vidē; vēlāks export terminālī neatjaunina jau darbojošos pakalpojumu.

Docker Desktop

Izmantojiet Desktop starpniekservera iestatījumus. Docker dokumentē, ka Desktop ignorē starpniekservera ierakstus daemon.json, tāpēc atkārtota tieši instalēta Engine piemēra maiņa neiestata šī produkta ceļu.

Pēc pareizā komponenta atjaunināšanas mēģiniet attēlu iegūt vēlreiz. Noskaidrojiet, vai neizdevās piekļuve reģistram, autentifikācija, pārvirzīšana vai slāņa lejupielāde. Darbojošs HTTP pieprasījums esošā konteinerā pārbauda tikai šīs lietotnes ceļu. Neiekļaujiet starpniekservera piekļuves datus kopīgotos ekrānuzņēmumos vai commit failos; dēmona konfigurācija un konteinera vide nav noslēpumu glabātavas.

Saistītie raksti