Hvorfor din virksomhedsproxy prøver at opløse et Compose-tjenestenavn

Applikationen når internettet gennem sin virksomhedsproxy, men http://catalog:8080/ fejler, og proxyen kan ikke opløse “catalog”. Den forespørgsel har muligvis aldrig brugt Dockers interne DNS.

En HTTP-klient kan vælge sin proxy, før den opretter en direkte forbindelse. Den eksterne proxy modtager derefter et navn, hvis betydning kun findes inde i Compose-netværket.

1. Brug værtsnavnet i forespørgslen. Compose-tjenester kan findes via tjenestenavn på det relevante netværk. Føj catalog til den forbrugende klients understøttede omgåelseskonfiguration i stedet for at hardkode en container-IP, der kan ændre sig.
2. Bevar eksisterende undtagelser. For en miljøbevidst klient skal du flette de relevante poster sammen med organisationens liste:

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

Kontrollér det faktiske bibliotek eller den kørbare fil i imaget for store og små bogstaver, version og matchningsgrammatik. Der findes ingen universel NO_PROXY-parser. Et program ved navn wget i et lille image behøver ikke opføre sig som GNU Wget.

Når forespørgslen vælger direkte routing, skal du kontrollere den delte netværkstilslutning for kalderen og tjenesten, den lyttende tjeneste og containerporten. En publiceret værtsport er et andet endepunkt. En omgåelse kan ikke tilføje en manglende netværkstilslutning, ligesom genskabelse af et netværk ikke kan lære en ekstern proxy et privat Compose-navn.

Behold den tilsigtede opdeling: interne forespørgsler bruger deres interne vej; eksterne forespørgsler beholder den godkendte proxy. Hvis du deaktiverer proxyen globalt, kan det skjule denne ene fejl, samtidig med at den fjerner den rute, der er nødvendig for den næste eksterne forespørgsel.