چرا پروکسی سازمانی شما می‌خواهد نام سرویس Compose را حل کند
یک کلاینت HTTP می‌تواند پیش از استفاده از حل نام سرویس Docker، درخواست سرویس داخلی را به پروکسی پیکربندی‌شده خود بفرستد. برای کلاینت مناسب، عبورهای عامدانه اضافه کنید.
برنامه از طریق پروکسی سازمانی خود به اینترنت دسترسی دارد، اما http://catalog:8080/ شکست می‌خورد و پروکسی نمی‌تواند “catalog” را حل کند. ممکن است آن درخواست هرگز از DNS داخلی Docker استفاده نکرده باشد.
یک کلاینت HTTP می‌تواند پیش از برقراری اتصال مستقیم، پروکسی خود را انتخاب کند. سپس پروکسی خارجی نامی را دریافت می‌کند که معنای آن فقط درون شبکه Compose وجود دارد.
- از نام میزبان در درخواست استفاده کنید. سرویس‌های Compose در شبکه مناسب با نام سرویس قابل کشف هستند.
catalogرا به پیکربندی عبور پشتیبانی‌شده کلاینت مصرف‌کننده اضافه کنید، به‌جای آنکه IP کانتینری را که ممکن است تغییر کند به‌صورت سخت‌کد بنویسید. - استثناهای موجود را حفظ کنید. برای کلاینتی که به محیط آگاه است، ورودی‌های مربوط را با فهرست سازمان ادغام کنید:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalogکتابخانه یا فایل اجرایی واقعی در ایمیج را از نظر مدیریت حروف بزرگ و کوچک، نسخه و دستور تطبیق بررسی کنید. تحلیلگر NO_PROXY جهانی وجود ندارد. برنامه‌ای به نام wget در یک ایمیج کوچک لازم نیست مانند GNU Wget رفتار کند.
پس از آنکه درخواست مسیریابی مستقیم را انتخاب کرد، شبکه مشترک فراخوان و سرویس، سرویس شنونده و پورت کانتینر را بررسی کنید. پورت میزبان منتشرشده نقطه پایانی دیگری است. عبور نمی‌تواند اتصال شبکه ازدست‌رفته را اضافه کند، همان‌گونه که بازسازی یک شبکه نمی‌تواند نام خصوصی Compose را به پروکسی خارجی بیاموزد.
تقسیم موردنظر را حفظ کنید: درخواست‌های داخلی از مسیر داخلی خود استفاده می‌کنند؛ درخواست‌های خارجی پروکسی تأییدشده را حفظ می‌کنند. غیرفعال کردن سراسری پروکسی می‌تواند این یک شکست را پنهان کند و در همان حال مسیر لازم برای درخواست خارجی بعدی را حذف کند.