خريطة proxies في Docker مرتبطة بالـdaemon وليس بالموقع

تبدو كائن JSON واعدًا: خريطة proxies فيها مدخل default ومفاتيح عناوين إضافية. من المغري وضع اسم مضيف registry هناك وتوقع أن تستخدم الطلبات المتجهة إلى ذلك الـregistry وكيلًا آخر.

تلك المفاتيح تحدد daemons الخاصة بـDocker التي يتصل بها العميل. وهي لا تحدد المواقع التي سيطلبها الحاوية.

يمكن لإعدادات عميل Docker أن تمنح الحاويات الجديدة متغيرات بيئة الوكيل، وأن تمنح عمليات البناء الجديدة وسائط بناء الوكيل. والمدخل الخاص بـdaemon معين يغيّر ذلك الإعداد الممنوح لسياق الـdaemon المطابق.

وهو لا يضبط اتصال الوكيل الصادر الخاص بالـdaemon نفسه. ولا يحوّل عميل HTTP في الحاوية إلى مُقيّم PAC.

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

قبل تحرير الخريطة، اكتب أي عنوان يمثله المفتاح وأي عملية تُصدر الطلب الفاشل. قد يظهر اسم المضيف نفسه في اتصال daemon وفي عنوان registry وفي عنوان وكيل، لكن هذه ثلاث أدوار مختلفة.