Docker əsas obrazlarının çəkilməsi: qurucu proksisi və build arqumentləri
Build addımlarına verilən proksi arqumentləri qurucunun etdiyi hər registry sorğusunu konfiqurasiya etmir. Əsas obrazı həll edən qurucunu müəyyənləşdirin.
Hər hansı Dockerfile paket endirmə addımı işləməzdən əvvəl FROM həll edilərkən build uğursuz ola bilər. Qurucunun registry müştərisi həmin əsas obrazı almaq üçün öz marşrutuna ehtiyac duyur.
| Əməliyyat | Marşruta ehtiyac duyan komponent |
|---|---|
| Əsas obrazı həll et və gətir | Qurucunun registry müştərisi |
| RUN zamanı endirmə | Build addımını icra edən proses |
| İşləmə zamanı API çağırışı | İşləyən tətbiq |
Qurucunu müəyyənləşdirin
Standart Docker drayveri demonu mərkəzə alır. Digər Buildx drayverləri ayrılmış BuildKit konteyneri, Kubernetes və ya uzaq xidmətdən istifadə edə bilər. Seçilmiş drayverin dəstəklədiyi proksi mexanizmini həmin işçinin işlədiyi yerdə konfiqurasiya edin.
Noutbukdakı loopback proksisi uzaq işçidən avtomatik əlçatan deyil və yerli demonu redaktə etmək həmin uzaq qurucunu yenidən konfiqurasiya etmir.
FROM-dan əvvəl ARG obraz istinadını seçməyə kömək edə bilər. Lakin bununla registry müştərisinin şəbəkə marşrutunu konfiqurasiya etmir. Paket parametrlərini yazan və ya sertifikat quraşdıran sonrakı RUN əmrləri bu əvvəlki sorğunu bərpa edə bilməz.
Etibar, hesablar və keşlənmiş məlumatlar
Təsdiqlənmiş CA materialı ilkin registry bağlantısını yoxlayan komponent üçün əlçatan olmalıdır. Registry etimadnamələri və proksi etimadnamələri fərqli tərəfləri səlahiyyətləndirir; registry girişi proksi 407-yə cavab verə bilməz.
Keşlənmiş obraz məlumatlarını təkrar istifadə edən işçi yeni işçinin etdiyi şəbəkə sorğusunu təkrarlamaya bilər. Faktiki qeydə alınmış əməliyyatı müqayisə edin. Əsas obraz girişi nəzərdə tutulan marşrutla işlədikdən sonra, sonrakı istənilən build addımı endirməsini həmin növbəti sərhəddə diaqnoz edin.