Waarom jou korporatiewe proxy 'n Compose-diensnaam probeer oplos

'n HTTP-kliënt kan 'n interne diensversoek na sy gekonfigureerde proxy stuur voordat dit Docker se diensnaam-resolusie gebruik. Voeg doelbewuste omseilings vir die regte kliënt by.

Die toepassing bereik die internet deur sy korporatiewe proxy, maar http://catalog:8080/ misluk en die proxy kan nie “catalog” oplos nie. Daardie versoek het moontlik nooit Docker se interne DNS gebruik nie.

'n HTTP-kliënt kan sy proxy kies voordat hy 'n direkte verbinding maak. Die eksterne proxy ontvang dan 'n naam waarvan die betekenis net binne die Compose-netwerk bestaan.

  1. Gebruik die gasheernaam in die versoek. Compose-dienste is op die toepaslike netwerk deur diensnaam vindbaar. Voeg catalog by die verbruikende kliënt se ondersteunde omseilkonfigurasie eerder as om 'n houer-IP hard te kodeer wat kan verander.
  2. Behou bestaande uitsonderings. Vir 'n omgewingsbewuste kliënt, voeg die relevante inskrywings by die organisasie-lys saam:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Kontroleer die werklike biblioteek of uitvoerbare lêer in die beeld vir hoofletterhantering, weergawe en passinggrammatika. Daar is geen universele NO_PROXY-ontleder nie. 'n Program met die naam wget in 'n klein beeld hoef nie soos GNU Wget op te tree nie.

Sodra die versoek direkte roetering kies, kontroleer die gedeelde netwerk van die oproeper en die diens, die luisterende diens en die houerpoort. 'n Gepubliseerde gasheempoort is 'n ander eindpunt. 'n Omseiling kan nie 'n ontbrekende netwerkaansluiting byvoeg nie, net soos die herskep van 'n netwerk nie 'n eksterne proxy 'n private Compose-naam kan leer nie.

Behou die beoogde verdeling: interne versoeke gebruik hul interne pad; eksterne versoeke behou die goedgekeurde proxy. Om die proxy globaal te deaktiveer kan hierdie een fout verberg terwyl dit die roete verwyder wat vir die volgende eksterne versoek nodig is.

Verwante artikels