Waarom je bedrijfsproxy een Compose-servicenaam probeert te resolven

De applicatie bereikt het internet via zijn bedrijfsproxy, maar http://catalog:8080/ mislukt en de proxy kan “catalog” niet resolven. Die aanvraag heeft mogelijk nooit de interne DNS van Docker gebruikt.

Een HTTP-client kan zijn proxy kiezen voordat hij een directe verbinding maakt. De externe proxy ontvangt dan een naam waarvan de betekenis alleen binnen het Compose-netwerk bestaat.

1. Gebruik de hostnaam in de aanvraag. Compose-services zijn vindbaar op servicenaam in het juiste netwerk. Voeg catalog toe aan de ondersteunde bypassconfiguratie van de consumerende client in plaats van een container-IP hard te coderen dat kan veranderen.
2. Behoud bestaande uitzonderingen. Voor een omgevingsbewuste client voeg je de relevante vermeldingen samen met de lijst van de organisatie:

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

Controleer de werkelijke bibliotheek of het uitvoerbare bestand in de image op hoofdlettergevoeligheid, versie en overeenkomende grammatica. Er bestaat geen universele NO_PROXY-parser. Een programma met de naam wget in een kleine image hoeft zich niet als GNU Wget te gedragen.

Zodra de aanvraag directe routing kiest, controleer je het gedeelde netwerk van de aanroeper en de service, de luisterende service en de containerpoort. Een gepubliceerde hostpoort is een ander eindpunt. Een bypass kan geen ontbrekende netwerkkoppeling toevoegen, net zoals het opnieuw aanmaken van een netwerk een externe proxy geen privénaam van Compose kan leren.

Behoud de bedoelde splitsing: interne aanvragen gebruiken hun interne pad; externe aanvragen behouden de goedgekeurde proxy. De proxy wereldwijd uitschakelen kan deze ene fout verbergen terwijl het de route verwijdert die nodig is voor de volgende externe aanvraag.