Kāpēc jūsu uzņēmuma starpniekserveris mēģina atrisināt Compose pakalpojuma nosaukumu

Lietojumprogramma sasniedz internetu caur savu uzņēmuma starpniekserveri, taču http://catalog:8080/ neizdodas, un starpniekserveris nevar atrisināt “catalog”. Iespējams, šis pieprasījums nekad nav izmantojis Docker iekšējo DNS.

HTTP klients var izvēlēties savu starpniekserveri pirms tieša savienojuma izveides. Tad ārējais starpniekserveris saņem nosaukumu, kura nozīme pastāv tikai Compose tīklā.

1. Izmantojiet resursdatora nosaukumu pieprasījumā. Compose pakalpojumi ir atrodami pēc pakalpojuma nosaukuma attiecīgajā tīklā. Pievienojiet catalog patērētāja klienta atbalstītajai apiešanas konfigurācijai, nevis stingri kodējiet konteinera IP, kas var mainīties.
2. Saglabājiet esošos izņēmumus. Videi apzinātam klientam apvienojiet attiecīgos ierakstus ar organizācijas sarakstu:

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

Pārbaudiet attēlā esošo faktisko bibliotēku vai izpildāmo failu attiecībā uz burtu reģistra apstrādi, versiju un atbilstības gramatiku. Nav universāla NO_PROXY parsētāja. Programma ar nosaukumu wget mazā attēlā nav jāuzvedas kā GNU Wget.

Kad pieprasījums izvēlas tiešu maršrutēšanu, pārbaudiet zvanītāja un pakalpojuma kopīgo tīklu, klausošos pakalpojumu un konteinera portu. Publicētais resursdatora ports ir cits galapunkts. Apiešana nevar pievienot trūkstošu tīkla savienojumu, tāpat kā tīkla atjaunošana nevar iemācīt ārējam starpniekserverim privātu Compose nosaukumu.

Saglabājiet paredzēto sadalījumu: iekšējie pieprasījumi izmanto savu iekšējo ceļu; ārējie pieprasījumi saglabā apstiprināto starpniekserveri. Starpniekservera globāla atspējošana var paslēpt šo vienu kļūdu, vienlaikus noņemot maršrutu, kas nepieciešams nākamajam ārējam pieprasījumam.