Docker asosiy obrazlarini tortish: quruvchi proksisi va build argumentlari
Build qadamlariga berilgan proksi argumentlari quruvchi yuboradigan har bir reyestr so'rovini sozlamaydi. Asosiy obrazni hal qiladigan quruvchini toping.
Har qanday Dockerfile paket yuklab olish qadami boshlanishidan oldin FROM hal qilinayotganda build muvaffaqiyatsiz bo'lishi mumkin. Quruvchining reyestr mijozi o'sha asosiy obrazni olish uchun o'z yo'liga muhtoj.
| Amal | Yo'l kerak bo'lgan komponent |
|---|---|
| Asosiy obrazni hal qilish va olish | Quruvchining reyestr mijozi |
| RUN vaqtida yuklab olish | Build qadamini bajaruvchi jarayon |
| Ish vaqtida API chaqirish | Ishlayotgan dastur |
Quruvchini toping
Standart Docker drayveri demon atrofida qurilgan. Boshqa Buildx drayverlari maxsus BuildKit konteyneri, Kubernetes yoki masofaviy xizmatdan foydalanishi mumkin. Tanlangan drayver qo'llab-quvvatlaydigan proksi mexanizmini shu worker ishlaydigan joyda sozlang.
Noutbukdagi loopback proksisiga masofaviy workerdan avtomatik kirib bo'lmaydi va mahalliy demonni tahrirlash o'sha masofaviy quruvchini qayta sozlamaydi.
FROM oldidagi ARG obraz havolasini tanlashga yordam beradi. Biroq bu bilan reyestr mijozining tarmoq yo'li sozlanmaydi. Keyinchalik paket sozlamalarini yozadigan yoki sertifikat o'rnatadigan RUN buyruqlari bu avvalgi so'rovni tuzata olmaydi.
Ishonch, hisoblar va keshlangan ma'lumotlar
Tasdiqlangan CA materiali reyestrning boshlang'ich ulanishini tekshiruvchi komponent uchun mavjud bo'lishi kerak. Reyestr va proksi hisob ma'lumotlari turli tomonlarga ruxsat beradi; reyestrga kirish proksining 407 javobini bera olmaydi.
Keshlangan obraz ma'lumotlarini qayta ishlatadigan worker yangi worker qiladigan bir xil tarmoq so'rovini takrorlamasligi mumkin. Haqiqatda qayd etilgan amalni solishtiring. Asosiy obrazga kirish mo'ljallangan yo'l orqali ishlagach, keyingi har qanday build qadami yuklanishini o'sha keyingi chegarada tashxislang.