Dlaczego firmowy proxy próbuje rozwiązać nazwę usługi Compose

Klient HTTP może wysłać żądanie wewnętrznej usługi do skonfigurowanego proxy, zanim użyje rozwiązywania nazw usług Dockera. Dodaj zamierzone obejścia dla właściwego klienta.

Aplikacja dociera do internetu przez firmowy proxy, ale http://catalog:8080/ zawodzi, a proxy nie może rozwiązać „catalog”. Możliwe, że to żądanie nigdy nie użyło wewnętrznego DNS Dockera.

Klient HTTP może wybrać swoje proxy przed nawiązaniem bezpośredniego połączenia. Zewnętrzne proxy otrzymuje wtedy nazwę, której znaczenie istnieje tylko w sieci Compose.

  1. Użyj nazwy hosta w żądaniu. Usługi Compose można odnaleźć po nazwie usługi w odpowiedniej sieci. Dodaj catalog do obsługiwanej konfiguracji obejścia klienta korzystającego z usługi, zamiast wpisywać na stałe adres IP kontenera, który może się zmienić.
  2. Zachowaj istniejące wyjątki. W przypadku klienta świadomego środowiska połącz odpowiednie wpisy z listą organizacji:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Sprawdź rzeczywistą bibliotekę lub plik wykonywalny w obrazie pod kątem obsługi wielkości liter, wersji i gramatyki dopasowania. Nie istnieje uniwersalny parser NO_PROXY. Program o nazwie wget w małym obrazie nie musi zachowywać się jak GNU Wget.

Gdy żądanie wybierze trasowanie bezpośrednie, sprawdź współdzieloną sieć wywołującego i usługi, nasłuchującą usługę oraz port kontenera. Opublikowany port hosta to inny punkt końcowy. Obejście nie może dodać brakującego przyłączenia sieciowego, tak jak odtworzenie sieci nie może nauczyć zewnętrznego proxy prywatnej nazwy Compose.

Zachowaj zamierzony podział: żądania wewnętrzne korzystają z wewnętrznej ścieżki; żądania zewnętrzne zachowują zatwierdzone proxy. Globalne wyłączenie proxy może ukryć ten jeden błąd, jednocześnie usuwając trasę potrzebną dla następnego żądania zewnętrznego.

Powiązane artykuły