Docker आधार-इमेज तान्ने: बिल्डर प्रोक्सी र बिल्ड आर्गुमेन्टहरू
बिल्ड चरणहरूलाई दिइएका प्रोक्सी आर्गुमेन्टहरूले बिल्डरले गर्ने हरेक रजिस्ट्री अनुरोध कन्फिगर गर्दैनन्। आधार इमेज समाधान गर्ने बिल्डर पत्ता लगाउनुहोस्।
कुनै पनि Dockerfile प्याकेज-डाउनलोड चरण चल्नु अघि FROM समाधान गर्दा बिल्ड असफल हुन सक्छ। बिल्डरको रजिस्ट्री क्लाइन्टलाई त्यो आधार इमेज प्राप्त गर्न आफ्नै मार्ग चाहिन्छ।
| सञ्चालन | मार्ग चाहिने कम्पोनेन्ट |
|---|---|
| आधार इमेज समाधान गरी ल्याउनुहोस् | बिल्डरको रजिस्ट्री क्लाइन्ट |
| RUN का क्रममा डाउनलोड | बिल्ड चरण चलाउने प्रक्रिया |
| रनटाइममा API कल गर्नु | चलिरहेको अनुप्रयोग |
बिल्डर पत्ता लगाउनुहोस्
पूर्वनिर्धारित Docker ड्राइभर डेमनमा केन्द्रित छ. अन्य Buildx ड्राइभरहरूले समर्पित BuildKit कन्टेनर, Kubernetes वा टाढाको सेवा प्रयोग गर्न सक्छन्। छानिएको ड्राइभरले समर्थन गर्ने प्रोक्सी संयन्त्र त्यो वर्कर चल्ने ठाउँमा कन्फिगर गर्नुहोस्।
ल्यापटपको लूपब्याक प्रोक्सी टाढाको वर्करबाट स्वतः पुग्न सकिँदैन, र स्थानीय डेमन सम्पादन गर्दा त्यो टाढाको बिल्डर पुनःकन्फिगर हुँदैन।
FROM अघिको ARG ले इमेज सन्दर्भ छान्न मद्दत गर्न सक्छ। तर यसले रजिस्ट्री क्लाइन्टको नेटवर्क मार्ग कन्फिगर गर्दैन। पछि प्याकेज सेटिङ लेख्ने वा प्रमाणपत्र स्थापना गर्ने RUN आदेशहरूले यो अघिल्लो अनुरोध सुधार्न सक्दैनन्।
विश्वास, खाता र क्यास गरिएको डाटा
स्वीकृत CA सामग्री प्रारम्भिक रजिस्ट्री जडान प्रमाणित गर्ने कम्पोनेन्टका लागि उपलब्ध हुनुपर्छ। रजिस्ट्री र प्रोक्सी प्रमाणहरूले फरक पक्षहरूलाई अधिकार दिन्छन्; रजिस्ट्री लगइनले प्रोक्सी 407 को जवाफ दिन सक्दैन।
क्यास गरिएको इमेज डाटा पुनः प्रयोग गर्ने वर्करले नयाँ वर्करले जस्तै त्यही नेटवर्क अनुरोध दोहोर्याउन नसक्छ। वास्तवमै लग गरिएको सञ्चालन तुलना गर्नुहोस्। आधार इमेजको पहुँच अभिप्रेत मार्गबाट काम गरेपछि, पछिको कुनै पनि बिल्ड-चरण डाउनलोडको त्यो अर्को सीमामा निदान गर्नुहोस्।