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 టైమౌట్ నివేదిస్తే, అడ్డంకి మార్గం లేదా రిజిస్ట్రీ ముందున్న ఎగ్రెస్ విధానం.

ప్రోబ్ సమాధానమిచ్చిన వెంటనే దాన్ని తొలగించండి. ఇది నిర్ధారణ దశ, దీనికి ఎప్పుడూ ట్యాగ్ లేదా 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 నెట్‌వర్కింగ్ గురించిన ఊహ కాదు.