آپ کا کارپوریٹ پراکسی Compose سروس کا نام کیوں حل کرنے کی کوشش کر رہا ہے
ایک HTTP کلائنٹ Docker کے سروس نام کی حل کاری استعمال کرنے سے پہلے اپنے ترتیب شدہ پراکسی کو اندرونی سروس کی درخواست بھیج سکتا ہے۔ صحیح کلائنٹ کے لیے جان بوجھ کر بائی پاس شامل کریں۔
ایپلیکیشن اپنی کارپوریٹ پراکسی کے ذریعے انٹرنیٹ تک پہنچتی ہے، لیکن http://catalog:8080/ ناکام ہو جاتا ہے اور پراکسی “catalog” کو حل نہیں کر سکتی۔ ممکن ہے اس درخواست نے کبھی Docker کے اندرونی DNS کو استعمال نہ کیا ہو۔
ایک HTTP کلائنٹ براہ راست کنکشن بنانے سے پہلے اپنی پراکسی منتخب کر سکتا ہے۔ پھر بیرونی پراکسی کو ایسا نام ملتا ہے جس کا مطلب صرف Compose نیٹ ورک کے اندر موجود ہوتا ہے۔
- درخواست میں ہوسٹ نام استعمال کریں۔ Compose سروسز مناسب نیٹ ورک پر سروس کے نام سے تلاش کی جا سکتی ہیں۔ بدل سکنے والے کنٹینر IP کو ہارڈ کوڈ کرنے کے بجائے صارف کلائنٹ کی معاون بائی پاس ترتیب میں
catalogشامل کریں۔ - موجودہ استثنات محفوظ رکھیں۔ ماحول سے آگاہ کلائنٹ کے لیے متعلقہ اندراجات کو تنظیم کی فہرست کے ساتھ ضم کریں:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalogامیج میں موجود اصل لائبریری یا قابلِ عمل فائل کا کیس ہینڈلنگ، ورژن اور ملاپ گرامر جانچیں۔ کوئی عالمگیر NO_PROXY پارسر نہیں ہے۔ چھوٹی امیج میں wget نامی پروگرام کا GNU Wget کی طرح برتاؤ ضروری نہیں۔
جب درخواست براہ راست روٹنگ منتخب کرے تو کال کرنے والے اور سروس کا مشترکہ نیٹ ورک، سننے والی سروس اور کنٹینر پورٹ جانچیں۔ شائع شدہ ہوسٹ پورٹ ایک اور اینڈ پوائنٹ ہے۔ بائی پاس غائب نیٹ ورک اٹیچمنٹ شامل نہیں کر سکتا، جیسے نیٹ ورک دوبارہ بنانا کسی بیرونی پراکسی کو نجی Compose نام نہیں سکھا سکتا۔
مطلوبہ تقسیم برقرار رکھیں: اندرونی درخواستیں اپنا اندرونی راستہ استعمال کرتی ہیں؛ بیرونی درخواستیں منظور شدہ پراکسی رکھتی ہیں۔ پراکسی کو عالمی طور پر غیر فعال کرنا اس ایک ناکامی کو چھپا سکتا ہے اور ساتھ ہی اگلی بیرونی درخواست کے لیے درکار راستہ ہٹا سکتا ہے۔