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 नेटवर्किंगबद्दलचा अंदाज नाही.