د Docker جوړېدل یوې شخصي اړیکې ته نه رسېږي: دا وګورئ
شخصي پیکج چې کوربه یې ترلاسه کولی شي، په build کې دننه بیا هم ناکام کېدلی شي. builder ونوموئ، لاره ثابته کړئ، بیا ټوکن د 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/
هغه فایل د هغه builder، د شبکې حالت او هغو پټو مونتونو سره build کړئ چې ستاسو ریښتینی build یې کاروي: docker buildx build --builder remote0 -f Dockerfile.probe --progress=plain .. که getent هیڅ ونه چاپوي، نیمګړتیا د نومونو په حل کې ده او هیڅ اعتبار به یې نه سمولای شي. که نوم حل شي خو curl د وخت د پای ته رسېدو خبر ورکړي، خنډ لاره یا د راجستر مخې ته د وتلو تګلاره ده.
کله چې ګوتې اچوونکی ځواب ورکړ، هغه له منځه یوسئ. دا تشخیصي پړاو دی او باید هیڅکله ټاګ یا push نشي.
اعتبار د کاپي کولو پرځای مونت کړئ
کله چې لاره کار وکړ، تصدیق په قطار کې بل ناکام دی. د BuildKit پټ مونت یو فایل یو RUN ګام ته ښکاره کوي، پرته له دې چې په پرت کې یې ولیکي؛ دا هغه څه دي چې د اړیکې وسیلې ته اړین دي او هغه څه چې image باید ونه ساتي.
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci --omit=dev
پټ باید د 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 سره پیل کړئ او ډاډ ترلاسه کړئ چې له مونت شوي پټ پرته پورته کېږي. هغه کنټینر چې یوازې د build پټ شتون کې پیلېږي، لا هم د build چاپېریال سره تړلی دی.
که کنټینر واقعاً د چلېدو په وخت راجستر ته اړتیا ولري، دا بېله لاسرسي پرېکړه ده، او ځای یې د orchestration پټ ذخیره ده نه build. دواړه لارې بېلې مستند کړئ ترڅو څوک د build بیرغ سره د چلېدو pull سمولو هڅه ونه کړي. کله چې پنځه ګوتې اچونې ټولې بریالۍ شي، اصلي نښه په هر پرت کې نومول شوی لامل لري، د Docker شبکې اړه اټکل نه.