कोई भी Dockerfile पैकेज-डाउनलोड चरण चलने से पहले FROM हल करते समय बिल्ड विफल हो सकता है। बिल्डर के रजिस्ट्री क्लाइंट को उस बेस इमेज को पाने के लिए अपना रास्ता चाहिए।

क्रियावह घटक जिसे रास्ता चाहिए
बेस इमेज हल करें और लाएँबिल्डर का रजिस्ट्री क्लाइंट
RUN के दौरान डाउनलोडबिल्ड चरण चलाने वाली प्रक्रिया
रनटाइम पर API कॉल करेंचल रहा एप्लिकेशन

बिल्डर का पता लगाएँ

डिफ़ॉल्ट Docker ड्राइवर डेमॉन पर केंद्रित है. अन्य Buildx ड्राइवर समर्पित BuildKit कंटेनर, Kubernetes या दूरस्थ सेवा का उपयोग कर सकते हैं। चुने गए ड्राइवर द्वारा समर्थित प्रॉक्सी तंत्र को वहाँ कॉन्फ़िगर करें जहाँ वह वर्कर चलता है।

लैपटॉप पर लूपबैक प्रॉक्सी दूरस्थ वर्कर से अपने आप पहुँच में नहीं होता, और स्थानीय डेमॉन संपादित करने से वह दूरस्थ बिल्डर फिर से कॉन्फ़िगर नहीं होता।

FROM से पहले का ARG इमेज संदर्भ चुनने में मदद कर सकता है। पर इससे रजिस्ट्री क्लाइंट का नेटवर्क रास्ता कॉन्फ़िगर नहीं होता। बाद में पैकेज सेटिंग लिखने या प्रमाणपत्र स्थापित करने वाले RUN आदेश इस पहले अनुरोध को ठीक नहीं कर सकते।

विश्वास, खाते और कैश किया गया डेटा

स्वीकृत CA सामग्री उस घटक के लिए उपलब्ध होनी चाहिए जो प्रारंभिक रजिस्ट्री कनेक्शन की पुष्टि करता है। रजिस्ट्री क्रेडेंशियल और प्रॉक्सी क्रेडेंशियल अलग-अलग पक्षों को अधिकृत करते हैं; रजिस्ट्री लॉगिन प्रॉक्सी 407 का उत्तर नहीं दे सकता।

कैश किए गए इमेज डेटा का पुनः उपयोग करने वाला वर्कर नए वर्कर जैसा वही नेटवर्क अनुरोध न दोहराए। वास्तव में लॉग किए गए संचालन की तुलना करें। बेस इमेज तक पहुँच इच्छित रास्ते से काम करने के बाद, आगे किसी भी बिल्ड-चरण डाउनलोड का उस अगली सीमा पर निदान करें।

संबंधित लेख