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/

اس فائل کو اسی builder، نیٹ ورک موڈ اور انہی secret ماؤنٹس کے ساتھ build کریں جو آپ کا اصل 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 نیٹ ورکنگ کے بارے میں اندازہ نہیں۔