რატომ ცდილობს თქვენი კორპორატიული პროქსი Compose სერვისის სახელის ამოხსნას

აპლიკაცია ინტერნეტს აღწევს თავისი კორპორატიული პროქსის მეშვეობით, მაგრამ http://catalog:8080/ ვერ მუშაობს და პროქსი ვერ ხსნის “catalog”-ს. შესაძლოა ამ მოთხოვნას არასდროს გამოუყენებია Docker-ის შიდა DNS.

HTTP კლიენტს შეუძლია აირჩიოს თავისი პროქსი პირდაპირი კავშირის დამყარებამდე. შემდეგ გარე პროქსი იღებს სახელს, რომლის მნიშვნელობაც მხოლოდ Compose ქსელის შიგნით არსებობს.

1. გამოიყენეთ ჰოსტის სახელი მოთხოვნაში. Compose სერვისები აღმოჩენადია სერვისის სახელით შესაბამის ქსელში. დაამატეთ catalog მომხმარებელი კლიენტის მხარდაჭერილ გვერდის ავლის კონფიგურაციაში, ნაცვლად იმისა, რომ ხისტად ჩაწეროთ კონტეინერის IP, რომელიც შეიძლება შეიცვალოს.
2. შეინარჩუნეთ არსებული გამონაკლისები. გარემოს გააზრებული კლიენტისთვის, შეუთავსეთ შესაბამისი ჩანაწერები ორგანიზაციის სიას:

NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

შეამოწმეთ გამოსახულებაში არსებული ფაქტობრივი ბიბლიოთეკა ან შესრულებადი ფაილი ასოების რეგისტრის დამუშავების, ვერსიისა და შესაბამისობის გრამატიკისთვის. უნივერსალური NO_PROXY პარსერი არ არსებობს. მცირე გამოსახულებაში wget-ის სახელწოდების პროგრამა არ უნდა მოიქცეს GNU Wget-ის მსგავსად.

მას შემდეგ, რაც მოთხოვნა აირჩევს პირდაპირ მარშრუტიზაციას, შეამოწმეთ გამომძახებლისა და სერვისის საერთო ქსელი, მოსმენადი სერვისი და კონტეინერის პორტი. გამოქვეყნებული ჰოსტის პორტი სხვა ბოლო წერტილია. გვერდის ავლა ვერ დაამატებს დაკარგულ ქსელურ კავშირს, ისევე როგორც ქსელის ხელახალი შექმნა ვერ ასწავლის გარე პროქსის პირად Compose სახელს.

შეინარჩუნეთ განზრახული გაყოფა: შიდა მოთხოვნები იყენებენ შიდა გზას; გარე მოთხოვნები ინარჩუნებენ დამტკიცებულ პროქსის. პროქსის გლობალურად გამორთვამ შეიძლება დამალოს ეს ერთი ხარვეზი, ხოლო წაშალოს შემდეგი გარე მოთხოვნისთვის საჭირო მარშრუტი.