لماذا لا يستخدم حاوية الوكيل حاوية DNS تلقائياً

تشغيل وكيل وخادم DNS على مضيف Docker واحد لا يصل بين مساري DNS الخاصين بهما. هناك ثلاث علاقات منفصلة مهمة:

• قابلية الوصول عبر الشبكة. عادةً ما يكون لمشاريع Compose المنفصلة شبكات افتراضية منفصلة. ضع الخدمات على شبكة مشتركة مناسبة، سواء داخل مشروع واحد أو عبر شبكة مشتركة صراحةً بين المشاريع.
• اكتشاف الخدمة. يمكن لـ DNS المضمَّن في شبكة Docker مخصّصة أن يحل أسماء الحاويات. هذا يتيح للتطبيق اكتشاف جاره؛ لكنه لا يختار ذلك الجار تلقائياً كمُحلِّل DNS له.
• اختيار المُحلِّل. حدِّد المُحلِّل المستخدم داخل حاوية الوكيل. يقبل حقل dns في Compose عناوين خوادم DNS. واسم مثل dns.local يُحل داخل تطبيق لا يصبح قيمة صالحة لذلك الحقل.

تتبَّع الاستعلام من حاوية الوكيل إلى عنوان المُحلِّل المُهيَّأ لها. تأكَّد من وجود مسار ومستمع DNS عند ذلك العنوان. نشر المنفذ 53 على المضيف ينشئ مسار وصول من جهة المضيف؛ لكنه لا يخبر الحاويات باستخدامه. الحاويات التي تتشارك شبكة قد تتواصل مباشرةً بدلاً من ذلك.

إذا كانت الإعدادات تشير إلى عنوان حاوية DNS، فأبقِه ثابتاً ضمن إعداد IPAM متوافق. العنوان المُخصَّص ديناميكياً والمنسوخ من حاوية الأمس قد يفشل عند إعادة الإنشاء. افحص أيضاً مسار المنبع للمُحلِّل: إعادة توجيه الاستعلامات غير المُجابة إلى نفسه تُنشئ فشلاً مختلفاً عن مُحلِّل غير قابل للوصول.

أخيراً، حدِّد مَن يحل الوجهة. وكيل HTTP يحل اسم CONNECT يمكنه استخدام مسار الحاوية هذا؛ أما عميل SOCKS الذي يحل محلياً فقد لا يفعل. بحث المضيف يثبت مسار المضيف، لا مسار عملية الوكيل.