Korporativ proksiniz niyə Compose xidmət adını həll etməyə çalışır

HTTP klienti Docker-in xidmət adı həllindən istifadə etməzdən əvvəl daxili xidmət sorğusunu konfiqurasiya edilmiş proksisinə göndərə bilər. Doğru klient üçün qəsdən yan keçmələr əlavə edin.

Tətbiq internetə korporativ proksisi vasitəsilə çatır, lakin http://catalog:8080/ uğursuz olur və proksi “catalog” adını həll edə bilmir. O sorğu Docker-in daxili DNS-indən heç vaxt istifadə etməmiş ola bilər.

HTTP klienti birbaşa bağlantı qurmazdan əvvəl proksisini seçə bilər. Sonra xarici proksi mənası yalnız Compose şəbəkəsinin içində olan bir ad alır.

  1. Sorğuda host adından istifadə edin. Compose xidmətləri uyğun şəbəkədə xidmət adı ilə tapıla bilər. Dəyişə bilən konteyner IP-sini kodla sabitləmək əvəzinə catalog -i istehlakçı klientin dəstəklədiyi yan keçmə konfiqurasiyasına əlavə edin.
  2. Mövcud istisnaları qoruyun. Mühiti nəzərə alan klient üçün müvafiq qeydləri təşkilat siyahısı ilə birləşdirin:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

İmajdakı faktiki kitabxana və ya icra olunan faylı hərf həssaslığı, versiya və uyğunlaşdırma qrammatikası baxımından yoxlayın. Universal NO_PROXY analizatoru yoxdur. Kiçik imajdakı wget adlı proqram GNU Wget kimi davranmağa borclu deyil.

Sorğu birbaşa marşrutlaşdırmanı seçdikdən sonra çağıranın və xidmətin ortaq şəbəkəsini, dinləyən xidməti və konteyner portunu yoxlayın. Yayımlanmış host portu başqa bir son nöqtədir. Yan keçmə çatışmayan şəbəkə qoşulmasını əlavə edə bilməz, necə ki şəbəkənin yenidən yaradılması xarici proksiyə şəxsi Compose adını öyrədə bilməz.

Nəzərdə tutulan bölgünü saxlayın: daxili sorğular öz daxili yolundan istifadə edir; xarici sorğular təsdiqlənmiş proksini saxlayır. Proksisi qlobal olaraq söndürmək bu bir uğursuzluğu gizlədə bilər, eyni zamanda növbəti xarici sorğu üçün lazım olan marşrutu silər.

Əlaqəli məqalələr