Ինչու docker pull-ը չի օգտագործում կոնտեյների պրոքսիի կարգավորումները

Եթե docker pull-ը ձախողվում է, կարգավորեք Docker դեյմոնը կամ Docker Desktop-ը։ Պատկերը ներբեռնվում է նախքան հավելվածի կոնտեյները կկարողանա կարդալ իր պրոքսիի փոփոխականները։

Բնիկ Docker Engine

Այս բաժինը միացրեք առկա դեյմոնի պրոքսիի կարգավորմանը, փոխարինեք փաստաթղթավորման վերջնակետը և պահեք չառնչվող կարգավորումները։ Հանրային պատկերների փորձերի համար, որտեղ հանրային պրոքսիները թույլատրված են, HTTP պրոքսիների ցանկը թեկնածուներ է տալիս․

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

Դեյմոնի գծիկներով բանալիները տարբերվում են Docker հաճախորդի ~/.docker/config.json-ի camelCase բանալիներից։ Հաճախորդի պրոքսիի բաժինը միջավայրի փոփոխականներ է տալիս նոր կոնտեյներներին և կառուցումներին։ Այն չի կարգավորում դեյմոնի ներբեռնումները կամ արդեն առկա կոնտեյներների միջավայրերը։

Կատարեք տեղադրման համար փաստաթղթավորված դեյմոնի վերագործարկումը՝ պլանավորելով ազդեցությունն ընթացիկ աշխատանքների վրա։ Դեյմոնը կարող է պրոքսիի փոփոխականները ստանալ նաև մեկնարկային միջավայրում։ Հետագայում տերմինալում export անելը չի թարմացնում աշխատող ծառայությունը։

Docker Desktop

Օգտագործեք Desktop-ի պրոքսիի կարգավորումները։ Docker-ը փաստաթղթավորում է, որ Desktop-ը անտեսում է daemon.json-ի պրոքսիի գրառումները։ Ուստի բնիկ Engine-ի օրինակը կրկնակի փոխելը չի կարգավորում այս արտադրանքի ուղին։

Ճիշտ բաղադրիչը թարմացնելուց հետո կրկին փորձեք պատկերն ստանալ։ Պարզեք՝ ձախողվել է գրանցամատյանի մուտքը, նույնականացումը, վերահղումները, թե շերտի ներբեռնումը։ Առկա կոնտեյների ներսում հաջող HTTP հարցումը միայն այդ հավելվածի ուղին է ստուգում։ Պրոքսիի մուտքի տվյալները մի ներառեք համօգտագործվող էկրանապատկերներում կամ commit արված ֆայլերում․ դեյմոնի կարգավորումն ու կոնտեյների միջավայրը գաղտնիքների պահոց չեն։