Docker-ის საბაზისო იმიჯების ჩამოტვირთვა: ამშენებლის პროქსი და build არგუმენტები
build ნაბიჯებისთვის მიცემული პროქსი არგუმენტები არ აკონფიგურირებს რეგისტრის ყველა მოთხოვნას, რომელსაც ამშენებელი აკეთებს. იპოვეთ ამშენებელი, რომელიც ხსნის საბაზისო იმიჯს.
build შეიძლება ჩავარდეს FROM-ის გადაწყვეტისას, სანამ Dockerfile-ის პაკეტის ჩამოტვირთვის რომელიმე ნაბიჯი გაეშვება. ამშენებლის რეგისტრის კლიენტს სჭირდება საკუთარი მარშრუტი ამ საბაზისო იმიჯის მისაღებად.
| ოპერაცია | კომპონენტი, რომელსაც მარშრუტი სჭირდება |
|---|---|
| საბაზისო იმიჯის გადაწყვეტა და მოტანა | ამშენებლის რეგისტრის კლიენტი |
| ჩამოტვირთვა RUN-ის დროს | პროცესი, რომელიც ასრულებს build ნაბიჯს |
| API-ის გამოძახება გაშვების დროს | მოქმედი აპლიკაცია |
იპოვეთ ამშენებელი
Docker-ის ნაგულისხმევი დრაივერი დემონზეა ორიენტირებული. სხვა Buildx დრაივერებს შეუძლიათ გამოიყენონ გამოყოფილი BuildKit კონტეინერი, Kubernetes ან დისტანციური სერვისი. დააკონფიგურირეთ არჩეული დრაივერის მხარდაჭერილი პროქსი მექანიზმი იქ, სადაც ეს worker მუშაობს.
ლეპტოპის loopback პროქსი ავტომატურად მიუწვდომელია დისტანციური worker-ისთვის და ლოკალური დემონის რედაქტირება არ გადააკონფიგურირებს ამ დისტანციურ ამშენებელს.
ARG FROM-ამდე დაგეხმარებათ იმიჯის მითითების არჩევაში. თუმცა ეს არ აკონფიგურირებს რეგისტრის კლიენტის ქსელურ მარშრუტს. მოგვიანებით RUN ბრძანებები, რომლებიც წერენ პაკეტის პარამეტრებს ან აყენებენ სერტიფიკატებს, ვერ შეაკეთებს ამ ადრინდელ მოთხოვნას.
ნდობა, ანგარიშები და ქეშირებული მონაცემები
დამტკიცებული CA მასალა უნდა იყოს ხელმისაწვდომი იმ კომპონენტისთვის, რომელიც ამოწმებს რეგისტრის საწყის კავშირს. რეგისტრისა და პროქსის სერტიფიკატები სხვადასხვა მხარეს ანიჭებს უფლებას; რეგისტრში შესვლა ვერ უპასუხებს პროქსის 407-ს.
worker, რომელიც ხელახლა იყენებს ქეშირებულ იმიჯის მონაცემებს, შეიძლება არ გაიმეოროს იგივე ქსელური მოთხოვნა, რასაც ახალი worker აკეთებს. შეადარეთ რეალურად დალოგილი ოპერაცია. როცა საბაზისო იმიჯზე წვდომა გამიზნული მარშრუტით იმუშავებს, დიაგნოსტიკა გაუკეთეთ ნებისმიერ შემდგომ build ნაბიჯის ჩამოტვირთვას ამ შემდეგ საზღვარზე.