VPN کے ذریعے docker pull: ڈیمن کا اپنا نیٹ ورک ہے

آپ کا لیپ ٹاپ کارپوریٹ VPN پر ہے، curl اندرونی رجسٹری تک پہنچتا ہے، پھر بھی docker pull EOF کے ساتھ ناکام ہوتا ہے۔ یہ امتزاج تضاد نہیں ہے۔ آپ نے جو حکم لکھا وہ آپ کے شیل میں چلتا ہے، لیکن منتقلی اُس ڈیمن کے اندر چلتی ہے جو Docker CLI نے منتخب کیا، اور وہ ڈیمن بالکل کسی اور ہوسٹ پر ہو سکتا ہے۔ اُس کا نیٹ ورک راستہ ہی کام کرنا چاہیے، اور اُس کی پراکسی ترتیبات ہی لاگو ہوتی ہیں۔

راستے سے نہیں، انجن کی شناخت سے شروع کریں

docker context show اور docker version چلائیں۔ ورژن کی آؤٹ پٹ ایک کلائنٹ حصہ اور ایک سرور حصہ چھاپتی ہے، اور سرور بلاک بتاتا ہے کہ کس نے جواب دیا: مقامی نیٹو انجن، Docker Desktop کی مجازی مشین، یا کسی دور مشین پر ڈیمن۔ اگر یقینی بنانا چاہیں تو docker context inspect منتخب سیاق کا آخری نقطہ دکھائے گا، اور اِن احکام میں سے کوئی بھی کچھ نہیں بدلتا۔

DOCKER_HOST جیسی ماحولیاتی متغیر CLI کو خاموشی سے اُس انجن کی طرف اشارہ کر سکتی ہے جو آپ سمجھ رہے ہیں اُس سے مختلف ہو، اور یہی اُس لیپ ٹاپ کی عام وضاحت ہے جو VPN پر دکھائی دیتا ہے جبکہ پل کہیں اور جاتا ہے۔

ڈیمن کی اپنی نیٹ ورک شناخت ہے

دور کے انجن کو نجی رجسٹری تک اپنا منظور شدہ راستہ درکار ہوتا ہے۔ آپ کے لیپ ٹاپ کا VPN کلائنٹ جوڑنے سے اُس لیپ ٹاپ کو راستہ ملتا ہے؛ اِس سے لیبارٹری یا کلاؤڈ سب نیٹ میں بیٹھے ڈیمن کو وہی نجی پتہ نہیں ملتا۔ اگر انجن Docker Desktop ہے تو پل اُس کی مجازی مشین کے اندر ہوتا ہے، جس کی اپنی نیٹ ورکنگ اور پراکسی ترتیب آپ کے شیل کے ماحول سے الگ ہے۔

اسی لیے ہوسٹ پر کامیاب curl صرف ہوسٹ کے بارے میں ثبوت ہے، اِس سے زیادہ کچھ نہیں۔

معلوم کریں کہ رجسٹری کے ساتھ کون سی منتقلی ختم ہوئی

امیج کا پل ایک ترتیب ہے: تصدیق، مینی فیسٹ کا حصول، اور پھر blob کی منتقلیاں جو اکثر آبجیکٹ اسٹوریج یا CDN کے آخری نقطے کی طرف ری ڈائریکٹ ہوتی ہیں۔ کامیاب docker login صرف پہلا مرحلہ ثابت کرتا ہے، اور ٹوکن مکمل طور پر درست ہو سکتا ہے جبکہ ری ڈائریکٹ شدہ blob ہوسٹ ڈیمن کے نیٹ ورک سے ناقابل رسائی ہو۔ کچھ بھی بدلنے سے پہلے درست وقت، امیج کا حوالہ اور ڈیمن یا کلائنٹ لاگ کی پہلی مفید واردات نوٹ کریں۔

EOF بذات خود کوئی وجہ نہیں بتاتا۔ یہ منقطع کنکشن، اسٹریم چھوڑنے والی پراکسی، وقت کی کمی یا MTU مسئلہ ہو سکتا ہے، اور وقت کے نشان والی واردات کے بغیر اِن کے درمیان اندازہ لگانا ہی وہ طریقہ ہے جس سے لوگ صحت مند انجن دوبارہ بناتے ہیں۔ کلائنٹ کی آؤٹ پٹ میں بائٹ آفسیٹ کو ڈیٹا سمجھیں، کیونکہ ہر بار ایک ہی سائز پر رکنے والی منتقلی اُس سے بالکل مختلف چیز ہے جو کبھی شروع نہیں ہوتی۔ دونوں نتائج نوٹ کریں اور کوششوں کے درمیان اُن کا موازنہ کریں۔

جو حصہ منتقلی کرتا ہے اُسے ترتیب دیں

نیٹو Linux انجن کے لیے پراکسی شیل میں نہیں، سروس کے ماحول میں ہوتی ہے۔ /etc/systemd/system/docker.service.d/ کے تحت HTTP_PROXY، HTTPS_PROXY اور NO_PROXY اندراجات والی drop-in فائل، پھر systemctl daemon-reload اور دوبارہ آغاز، یہی دستاویزی ترتیب ہے۔ Docker Desktop وہی اقدار اپنی ترتیبات کے ذریعے پیش کرتا ہے، اور شیل پروفائل میں ترمیم اِن میں سے کسی کو نہیں چھوتی۔

اگر رجسٹری تک براہ راست VPN کے ذریعے پہنچنا ہو تو ڈیمن کو ریزولوور، راستہ اور جان بوجھ کر کی گئی پراکسی استثنا درکار ہے، صرف استثنا نہیں۔ NO_PROXY کی مطابقت ہر حصے کے لیے متن کا موازنہ ہے، اور بنیادی راستے کے بغیر استثنا ایسی ناکامی پیدا کرتا ہے جو پراکسی کے مسئلے جیسی لگتی ہے۔

جب انٹرپرائز TLS معائنہ منظور شدہ راستے پر ہو تو اُس کی تصدیق شدہ جڑ انجن یا Desktop کے ورک فلو کے ذریعے نصب کریں۔ رجسٹری کو insecure-registries میں شامل کرنا ایک اور تبدیلی ہے جو تصدیق بند کر دیتی ہے، اور یہ ٹرسٹ اسٹور کی ترتیب نہیں ہے۔

ایک کنٹرول شدہ پل دہرائیں اور دیکھیں کہ کیا بدلا

ایک حد بدلیں، اُس کا مالک حصہ دوبارہ شروع کریں، اور اُسی سیاق سے وہی پل دہرائیں۔ نتیجے میں ملنے والا امیج حوالہ اور digest تصدیق کریں، غلطی کی عدم موجودگی نہیں، کیونکہ کیش شدہ تہہ دوسری کوشش کو پہلی سے بہت کم راستہ گزار سکتی ہے۔ حقیقت میں ہونے والی منتقلیاں ٹکٹ میں رکھیں، کیونکہ دوبارہ کوشش نے واقعی کیا جانچا اُس کا وہی واحد ریکارڈ ہے۔

بلڈ کے مراحل اور چلتے کنٹینرز کے اپنے نیٹ ورک سیاق ہوتے ہیں، اس لیے پل خود کام کرنے کے بعد اُنہیں الگ سوالات سمجھیں۔