Docker build निजी निर्भरतासम्म पुग्दैन: यो जाँच्नुहोस्

तपाईंको मेसिनमा सजिलै समाधान हुने निजी प्याकेज build भित्र 404 वा टाइमआउटसँग असफल हुन सक्छ, र Dockerfile यसको कारण हुनु दुर्लभ छ। build चरण अर्को नेटवर्क नेमस्पेसमा चल्छ, फरक DNS दृश्य र फरक क्रेडेन्सियल भण्डारसहित, तपाईंले परीक्षण गरेको shell भन्दा फरक। यी जाँचहरू क्रममा गर्नुहोस् र पहिलो असफल हुनेमा रोक्नुहोस्, किनकि प्रत्येक पछिल्लो जाँचले अघिल्लो पास भएको मान्छ। प्रत्येक चरणले विषय टुंग्याउने आदेशको नाम बताउँछ।

Dockerfile होइन, builder को नामबाट सुरु गर्नुहोस्

BuildKit स्थानीय, कन्टेनरमा वा अर्को मेसिनमा चल्न सक्छ, र प्रत्येकको आफ्नै पूर्वनिर्धारित नेटवर्क हुन्छ। चलाउनुहोस् docker buildx ls र केही परिवर्तन गर्नुअघि तारा चिन्ह लागेको नोड पढ्नुहोस्। एउटा docker-container ड्राइभर वा क्लाउड builder ले तपाईंले त्यहाँ आदेश टाइप गर्नुभयो भनेर मात्र तपाईंको ल्यापटपको निजी मार्ग साझा गर्दैन। यदि सक्रिय builder टाढा छ भने, बाँकी हरेक जाँच तपाईंको वर्कस्टेशनमा होइन, त्यही होस्टमा चलाउनुपर्छ।

builder ले आफ्नै resolver कन्फिगरेसन र proxy चरहरूपनि बोक्छ। दुवै build को समयमा पढिन्छन् र build सुरु गर्ने टर्मिनलबाट वंशानुगत रूपमा आउँदैनन्।

build चरणको भित्रबाट नेटवर्क मार्ग प्रमाणित गर्नुहोस्

निर्भरताको होस्ट समाधान गर्ने र त्यसमा जडान खोल्ने एकपटकको चरण लेख्नुहोस्। builder का लागि प्रश्नको उत्तर दिने यही एउटै परीक्षण हो, तपाईंको shell का लागि होइन।

FROM alpine:3.20
RUN apk add --no-cache curl bind-tools  && getent hosts registry.example.internal  && curl -sS -o /dev/null -w "%{http_code}
" https://registry.example.internal/simple/

तपाईंको वास्तविक build ले प्रयोग गर्ने त्यही builder, नेटवर्क मोड र secret माउन्टहरूसँग त्यो फाइल build गर्नुहोस्: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. यदि getent केही छाप्दैन भने, दोष नाम-समाधानमा छ र कुनै क्रेडेन्सियलले त्यो सुधार्दैन। नाम समाधान हुन्छ तर curl ले टाइमआउट जनाउँछ भने, अवरोध मार्ग वा रजिस्ट्रीअगाडिको इग्रेस नीति हो।

प्रोबले जवाफ दिने बित्तिकै त्यो मेट्नुहोस्। यो निदान चरण हो र यसलाई कहिल्यै ट्याग वा पुश गर्नु हुँदैन।

क्रेडेन्सियल प्रतिलिपि गर्नुको सट्टा माउन्ट गर्नुहोस्

मार्ग चलेपछि, अर्को असफलता प्रमाणीकरण हो। BuildKit secret माउन्टले एउटा फाइललाई एउटा RUN चरणसम्म मात्र खोल्छ, त्यो तहमा नलेखी; निर्भरता उपकरणलाई यही चाहिन्छ र image ले यो राख्नु हुँदैन।

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc     npm ci --omit=dev

secret Dockerfile बाहिरबाट उपलब्ध गराउनुपर्छ: docker buildx build --secret id=npmrc,src=/home/me/.npmrc .. फाइल क्लाइन्टसँगै रहन्छ र कहिल्यै image इतिहासमा जाँदैन। एउटा ARG वा ENV उही टोकनसहित यो काम गर्दैन, किनकि दुवै image कन्फिगरेसनमा अभिलेख हुन्छन्।

root नभएको image लाई आफ्नै लक्ष्य मार्ग चाहिन्छ, जस्तै /home/app/.npmrc वा pip, Maven वा Cargo का लागि समान फाइल। माउन्ट लक्ष्य आदेश चलाउने प्रयोगकर्तासँग मिल्नुपर्छ, नत्र उपकरणले वास्तवमा भएको कन्फिगरेसन फाइल हराएको भनी जनाउनेछ।

निर्भरता उपकरणले image मा के छोड्छ त्यो जाँच्नुहोस्

अस्थायी माउन्टले क्रेडेन्सियललाई तहबाहिर राख्छ, तर उपकरणलाई अरू केही लेख्नबाट रोक्दैन। प्याकेज प्रबन्धकहरूले lock फाइल, cache निर्देशिका र कहिलेकाहीँ समाधान भएको रजिस्ट्री URL छोड्छन्।

Dockerfile माथि भरोसा गर्नुको सट्टा तयार फाइलसिस्टम पढ्नुहोस्। docker history --no-trunc image:tag प्रत्येक तह आदेश सूचीबद्ध गर्छ, र docker run --rm image:tag sh -c "ls -a /root" चलिरहेको कन्टेनरमा के बाँच्यो देखाउँछ। फाइल मात्र माउन्ट गरिएको भए पनि, लग लाइनमा लेखिएको टोकन npm ci क्रममा पनि चुहावट नै रहन्छ।

build लग पनि पढ्नुहोस्, किनकि --progress=plain आदेशको आउटपुट शब्दशः छाप्छ। टोकन त्यहाँ देखियो भने, अरू सबैभन्दा पहिले त्यो घुमाउनुहोस् र उपकरणले चुपचाप पढ्ने फाइलमार्फत पठाउनुहोस्।

रनटाइम image लाई अब निजी मार्ग चाहिँदैन भनी पुष्टि गर्नुहोस्

build र चलिरहेको एप्लिकेसन एउटै निर्भरताका दुई फरक उपभोक्ता हुन्, र निजी मार्ग पहिलोलाई मात्र चाहिन्छ। तयार image build समयको क्रेडेन्सियलबिना सुरु हुनुपर्छ, आफ्ना रनटाइम निर्भरता समाधान गर्नुपर्छ र ट्राफिक सेवा दिनुपर्छ।

निजी रजिस्ट्री पुग्न नसकिने ठाउँमा यो परीक्षण गर्नुहोस्, वा कन्टेनरलाई मात्र --network none सँग सुरु गर्नुहोस् र माउन्ट गरिएको secret बिना यो बुट हुन्छ भनी पुष्टि गर्नुहोस्। build secret हुँदा मात्र सुरु हुने कन्टेनर अझै build वातावरणसँग बाँधिएको छ।

कन्टेनरलाई रनटाइममा रजिस्ट्री साँच्चै चाहिन्छ भने, त्यो छुट्टै पहुँच निर्णय हो, र त्यसको ठाउँ अर्केस्ट्रेटरको secret भण्डारमा हो, build मा होइन। दुवै मार्ग अलग-अलग अभिलेख गर्नुहोस् ताकि कसैले build फ्ल्यागले रनटाइम पुल सुधार्ने प्रयास नगरोस्। पाँचै जाँच पास भएपछि, मूल लक्षणको प्रत्येक तहमा नाम दिइएको कारण हुन्छ, Docker नेटवर्किङबारे अनुमान होइन।