Waarom docker pull jou houer se instaanbedienerinstellings ignoreer

Stel die Docker-deel op wat werklik beelde aflaai, eerder as om te verwag dat houer-instaanbedienerveranderlikes die daemon beheer.

As docker pull misluk, stel die Docker-daemon of Docker Desktop op. Die beeld word afgelaai voordat die toepassinghouer sy instaanbedienerveranderlikes kan lees.

Inheemse Docker Engine

Voeg dié deel by die bestaande daemon-instaanbedieneropstelling, vervang die dokumentasie-eindpunt en behou onverwante instellings. Vir toetse met openbare beelde waar openbare instaanbedieners toegelaat word, gee die HTTP-instaanbedienerlys kandidate:

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

Die daemon se sleutels met koppeltekens verskil van die camelCase-sleutels in die Docker-kliënt se ~/.docker/config.json. Die kliënt se instaanbedienerdeel verskaf omgewingsveranderlikes aan nuwe houers en bouprosesse; dit stel nie daemon-aflaaie of die omgewing van bestaande houers op nie.

Herbegin die daemon volgens die installasie se dokumentasie en beplan die uitwerking op huidige werklaste. Die daemon kan ook instaanbedienerveranderlikes in sy beginomgewing ontvang; ’n latere export in ’n terminaal werk nie ’n lopende diens by nie.

Docker Desktop

Gebruik Desktop se instaanbedienerinstellings. Docker dokumenteer dat Desktop instaanbedienerinskrywings in daemon.json ignoreer, dus stel herhaalde veranderinge aan die inheemse Engine-voorbeeld nie dié produk se pad op nie.

Probeer die beeld weer aflaai nadat die regte deel bygewerk is. Lees of registertoegang, verifikasie, herleidings of laagaflaai misluk het. ’n Werkende HTTP-versoek binne ’n bestaande houer kontroleer net daardie toepassing se roete. Hou instaanbedieneraanmeldbesonderhede uit gedeelde skermgrepe en gecommitte lêers; daemonopstelling en houeromgewing is nie geheimekluise nie.

Verwante artikels