چرا کانتینر پروکسی به‌طور خودکار از کانتینر DNS استفاده نمی‌کند

اجرای پروکسی و سرور DNS روی یک میزبان Docker مسیرهای DNS آن‌ها را به هم وصل نمی‌کند. سه رابطه جداگانه اهمیت دارند:

• دسترس‌پذیری شبکه. پروژه‌های جداگانه Compose معمولاً شبکه‌های پیش‌فرض جداگانه دارند. سرویس‌ها را روی یک شبکه مشترک مناسب قرار دهید، چه درون یک پروژه و چه از طریق شبکه‌ای که صریحاً میان پروژه‌ها مشترک است.
• کشف سرویس. DNS تعبیه‌شده در یک شبکه Docker سفارشی می‌تواند نام کانتینرها را تفکیک کند. این به برنامه اجازه می‌دهد همسایه‌ای را کشف کند؛ اما آن همسایه را به‌طور خودکار به‌عنوان resolver DNS خود انتخاب نمی‌کند.
• انتخاب resolver. resolverی را که درون کانتینر پروکسی استفاده می‌شود مشخص کنید. فیلد dns در Compose نشانی سرورهای DNS را می‌پذیرد. نامی مانند dns.local که در یک برنامه تفکیک می‌شود، آن را به مقدار معتبری برای آن فیلد تبدیل نمی‌کند.

پرس‌وجو را از کانتینر پروکسی تا نشانی resolver پیکربندی‌شده‌اش دنبال کنید. وجود یک مسیر و یک شنونده DNS در آن نشانی را تأیید کنید. انتشار پورت 53 میزبان یک مسیر دسترسی در سمت میزبان ایجاد می‌کند؛ اما به کانتینرها نمی‌گوید از آن استفاده کنند. کانتینرهایی که شبکه‌ای را به اشتراک می‌گذارند می‌توانند در عوض مستقیم ارتباط برقرار کنند.

اگر پیکربندی به نشانی کانتینر DNS اشاره می‌کند، آن را تحت پیکربندی سازگار IPAM پایدار نگه دارید. نشانی‌ای که به‌صورت پویا تخصیص یافته و از کانتینر دیروز کپی شده باشد می‌تواند هنگام بازسازی شکست بخورد. مسیر بالادستی resolver را نیز بررسی کنید: فرستادن پرس‌وجوهای بی‌پاسخ به خودش خرابی متفاوتی از resolver دسترس‌ناپذیر ایجاد می‌کند.

در پایان، مشخص کنید چه کسی مقصد را تفکیک می‌کند. پروکسی HTTP که نام CONNECT را تفکیک می‌کند می‌تواند از این مسیر کانتینر استفاده کند؛ کلاینت SOCKS که به‌صورت محلی تفکیک می‌کند ممکن است نکند. جست‌وجو روی میزبان مسیر میزبان را اثبات می‌کند، نه مسیر فرایند پروکسی را.