Docker build தனியுரிமைச் சார்பை அடையவில்லை: இதைச் சரிபார்க்கவும்
புரவலன் பெறக்கூடிய தனியுரிமைத் தொகுப்பும் build-க்குள் தோல்வியடையலாம். builder-ஐப் பெயரிடுங்கள், பாதையை நிரூபியுங்கள், பின்னர் டோக்கனை build secret ஆக ஏற்றுங்கள்.
உங்கள் இயந்திரத்தில் சிக்கலின்றி தீர்க்கப்படும் தனியுரிமைத் தொகுப்பு 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 நேர முடிவைத் தெரிவித்தால், தடையானது பாதை அல்லது பதிவேட்டின் முன்னால் உள்ள வெளியேற்றக் கொள்கை.
ஆய்வி பதிலளித்த உடனேயே அதை நீக்குங்கள். இது கண்டறியும் படிநிலை, இதற்கு ஒருபோதும் குறிச்சொல் அல்லது push செய்யக்கூடாது.
அடையாளச் சான்றை நகலெடுப்பதற்குப் பதிலாக ஏற்றுங்கள்
பாதை வேலை செய்தபின், அடுத்த தோல்வி அங்கீகாரம். 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 வலைப்பிணையம் பற்றிய ஊகம் அல்ல.