Korporativ proksingiz nima uchun Compose xizmat nomini hal qilishga urinadi

HTTP mijozi Docker'ning xizmat nomini hal qilishidan oldin ichki xizmat so'rovini sozlangan proksisiga yuborishi mumkin. To'g'ri mijoz uchun ataylab chetlab o'tishlarni qo'shing.

Ilova internetga korporativ proksisi orqali chiqadi, lekin http://catalog:8080/ muvaffaqiyatsiz bo'ladi va proksi “catalog”ni hal qila olmaydi. Bu so'rov Docker'ning ichki DNS'ini hech qachon ishlatmagan bo'lishi mumkin.

HTTP mijozi to'g'ridan-to'g'ri ulanishdan oldin proksisini tanlashi mumkin. Shunda tashqi proksi ma'nosi faqat Compose tarmog'i ichida mavjud bo'lgan nomni oladi.

  1. So'rovda xost nomidan foydalaning. Compose xizmatlari tegishli tarmoqda xizmat nomi bilan topiladi. O'zgarishi mumkin bo'lgan konteyner IP'sini qattiq kodlash o'rniga catalog ni iste'molchi mijozning qo'llab-quvvatlanadigan chetlab o'tish sozlamasiga qo'shing.
  2. Mavjud istisnolarni saqlang. Muhitdan xabardor mijoz uchun tegishli yozuvlarni tashkilot ro'yxati bilan birlashtiring:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Tasvirdagi haqiqiy kutubxona yoki bajariladigan faylni katta-kichik harflarni qayta ishlash, versiya va moslik grammatikasi bo'yicha tekshiring. Universal NO_PROXY tahlilchisi yo'q. Kichik tasvirdagi wget nomli dastur GNU Wget kabi ishlashi shart emas.

So'rov to'g'ridan-to'g'ri marshrutlashni tanlagach, chaqiruvchi va xizmatning umumiy tarmog'ini, tinglayotgan xizmatni va konteyner portini tekshiring. E'lon qilingan xost porti boshqa so'nggi nuqtadir. Chetlab o'tish yetishmayotgan tarmoq ulanishini qo'sha olmaydi, xuddi tarmoqni qayta yaratish tashqi proksiga xususiy Compose nomini o'rgata olmaganidek.

Ko'zda tutilgan bo'linishni saqlang: ichki so'rovlar o'z ichki yo'lidan foydalanadi; tashqi so'rovlar tasdiqlangan proksini saqlaydi. Proksini butunlay o'chirish bu bitta nosozlikni yashirishi va keyingi tashqi so'rov uchun zarur bo'lgan marshrutni olib tashlashi mumkin.

O'xshash maqolalar