რატომ უგულებელყოფს 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 გასაღებებისგან. კლიენტის პროქსის ნაწილი გარემოს ცვლადებს აძლევს ახალ კონტეინერებს და build-ებს; ის არ აყენებს დემონის ჩამოტვირთვებს ან უკვე არსებული კონტეინერების გარემოს.

შეასრულეთ ინსტალაციისთვის დოკუმენტირებული დემონის გადატვირთვა და დაგეგმეთ მიმდინარე სამუშაოებზე გავლენა. დემონს პროქსი ცვლადების მიღება გაშვების გარემოშიც შეუძლია; მოგვიანებით ტერმინალში export არ განაახლებს უკვე მომუშავე სერვისს.

Docker Desktop

გამოიყენეთ Desktop-ის პროქსის პარამეტრები. Docker-ის დოკუმენტაციით, Desktop უგულებელყოფს daemon.json-ის პროქსის ჩანაწერებს, ამიტომ უშუალო Engine-ის მაგალითის განმეორებით შეცვლა ამ პროდუქტის გზას ვერ გამართავს.

სწორი კომპონენტის განახლების შემდეგ ხელახლა ჩამოტვირთეთ იმიჯი. გაარჩიეთ, registry-ზე წვდომა ჩავარდა, ავთენტიფიკაცია, გადამისამართება თუ ფენის ჩამოტვირთვა. არსებულ კონტეინერში წარმატებული HTTP მოთხოვნა მხოლოდ იმ აპის გზას ამოწმებს. პროქსის ავტორიზაციის მონაცემები არ მოათავსოთ გაზიარებულ ეკრანის სურათებში ან commit-ებულ ფაილებში; დემონის კონფიგურაცია და კონტეინერის გარემო საიდუმლოებების საცავი არ არის.