پروکسی کنٹینر DNS کنٹینر کو خودکار طور پر کیوں استعمال نہیں کرتا

ایک ہی Docker ہوسٹ پر پراکسی اور DNS سرور چلانا ان کے DNS راستوں کو نہیں جوڑتا۔ تین الگ تعلقات اہم ہیں:

• نیٹ ورک تک رسائی۔ الگ Compose منصوبوں کے عام طور پر الگ ڈیفالٹ نیٹ ورک ہوتے ہیں۔ سروسز کو موزوں مشترکہ نیٹ ورک پر رکھیں، خواہ ایک منصوبے کے اندر یا منصوبوں کے درمیان واضح طور پر مشترکہ نیٹ ورک کے ذریعے۔
• سروس کی دریافت۔ حسب ضرورت Docker نیٹ ورک کا سرایت شدہ DNS کنٹینر نام حل کر سکتا ہے۔ اس سے ایپلیکیشن کو ہمسایہ دریافت کرنے کی اجازت ملتی ہے؛ تاہم یہ اس ہمسایہ کو خودکار طور پر اپنا DNS ریزولور نہیں بناتا۔
• ریزولور کا انتخاب۔ پراکسی کنٹینر کے اندر استعمال ہونے والا ریزولور شناخت کریں۔ Compose کا dns فیلڈ DNS سرور کے پتے لیتا ہے۔ dns.local جیسا نام جو ایپلیکیشن میں حل ہوتا ہے، اسے اس فیلڈ کے لیے درست قدر نہیں بناتا۔

استفسار کو پراکسی کنٹینر سے اس کے تشکیل شدہ ریزولور پتے تک ٹریس کریں۔ تصدیق کریں کہ اس پتے پر راستہ اور DNS سامع موجود ہے۔ ہوسٹ پورٹ 53 شائع کرنا ہوسٹ کی طرف رسائی کا راستہ بناتا ہے؛ تاہم یہ کنٹینروں کو اسے استعمال کرنے کو نہیں کہتا۔ نیٹ ورک مشترکہ رکھنے والے کنٹینر اس کے بجائے براہ راست رابطہ کر سکتے ہیں۔

اگر کنفیگریشن DNS کنٹینر کے پتے کا حوالہ دیتی ہے تو اسے ہم آہنگ IPAM کنفیگریشن کے تحت مستحکم رکھیں۔ کل کے کنٹینر سے نقل کیا گیا متحرک طور پر مختص پتہ دوبارہ تخلیق پر ناکام ہو سکتا ہے۔ ریزولور کے بالائی راستے کا بھی معائنہ کریں: بغیر جواب والے استفسارات واپس اسی کی طرف بھیجنا ناقابل رسائی ریزولور سے مختلف ناکامی پیدا کرتا ہے۔

آخر میں، شناخت کریں کہ منزل کون حل کرتا ہے۔ CONNECT نام حل کرنے والا HTTP پراکسی یہ کنٹینر راستہ استعمال کر سکتا ہے؛ مقامی طور پر حل کرنے والا SOCKS کلائنٹ شاید نہ کرے۔ ہوسٹ پر تلاش ہوسٹ کے راستے کا ثبوت دیتی ہے، پراکسی عمل کے راستے کا نہیں۔