لماذا يحاول الوكيل المؤسسي لديك تحليل اسم خدمة Compose

يصل التطبيق إلى الإنترنت عبر الوكيل المؤسسي، لكن http://catalog:8080/ يفشل ولا يستطيع الوكيل تحليل “catalog”. ربما لم يستخدم ذلك الطلب نظام DNS الداخلي في Docker قط.

يمكن لعميل HTTP اختيار وكيله قبل إنشاء اتصال مباشر. عندئذ يتلقى الوكيل الخارجي اسمًا يوجد معناه فقط داخل شبكة Compose.

1. استخدم اسم المضيف في الطلب. يمكن اكتشاف خدمات Compose باسم الخدمة على الشبكة المناسبة. أضف catalog إلى تهيئة التجاوز المدعومة لدى العميل المستهلك بدلًا من ترميز عنوان IP للحاوية بشكل ثابت قد يتغير.
2. حافظ على الاستثناءات القائمة. بالنسبة لعميل يدرك البيئة، ادمج الإدخالات ذات الصلة مع قائمة المؤسسة:

NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

تحقق من المكتبة أو الملف التنفيذي الفعلي في الصورة من حيث التعامل مع حالة الأحرف والإصدار وقواعد المطابقة. لا يوجد محلل NO_PROXY عالمي. البرنامج المسمى wget في صورة صغيرة ليس بالضرورة أن يتصرف مثل GNU Wget.

بعد أن يختار الطلب التوجيه المباشر، تحقق من الشبكة المشتركة بين المستدعي والخدمة، والخدمة المستمعة، ومنفذ الحاوية. منفذ المضيف المنشور هو نقطة نهاية أخرى. لا يمكن للتجاوز إضافة ارتباط شبكة مفقود، كما لا يمكن لإعادة إنشاء شبكة أن تعلّم وكيلًا خارجيًا اسم Compose خاصًا.

احتفظ بالفصل المقصود: تستخدم الطلبات الداخلية مسارها الداخلي؛ وتحتفظ الطلبات الخارجية بالوكيل المعتمد. تعطيل الوكيل عالميًا قد يخفي هذا الفشل الواحد بينما يزيل المسار اللازم للطلب الخارجي التالي.