Hvers vegna fyrirtækisproxyið þitt reynir að leysa Compose-þjónustuheiti

Forritið nær til internetsins í gegnum fyrirtækisproxyið sitt, en http://catalog:8080/ mistekst og proxyið getur ekki leyst “catalog”. Þessi beiðni notaði kannski aldrei innra DNS Docker.

HTTP-biðlari getur valið proxyið sitt áður en hann býr til beina tengingu. Ytra proxyið fær þá heiti þar sem merkingin er aðeins til inni í Compose-netinu.

1. Notaðu hýsingarheitið í beiðninni. Compose-þjónustur er að finna eftir þjónustuheiti á viðeigandi neti. Bættu catalog við studda framhjáhlaupsskráningu biðlarans sem notar hana í stað þess að harðkóða IP-tölu gáms sem getur breyst.
2. Varðveittu fyrirliggjandi undantekningar. Fyrir umhverfismeðvitaðan biðlara, sameinaðu viðeigandi færslur við listann hjá fyrirtækinu:

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

Athugaðu raunverulega bókasafnið eða keyrsluskrána í myndinni varðandi há- og lágstafi, útgáfu og samsvörunarmálfræði. Það er ekkert algilt NO_PROXY-þáttara. Forrit að nafni wget í lítilli mynd þarf ekki að hegða sér eins og GNU Wget.

Þegar beiðnin velur beina leiðsögn, athugaðu sameiginlegt net kallandans og þjónustunnar, þjónustuna sem hlustar og gámsportið. Birt hýsingarport er annar endapunktur. Framhjáhlaup getur ekki bætt við vantar nettengi, eins og endurgerð nets getur ekki kennt ytra proxyi einkarekinu Compose-heiti.

Haltu fyrirhugaðri skiptingu: innri beiðnir nota innri leið sína; ytri beiðnir halda samþykktu proxyi. Að slökkva á proxyinu á heimsvísu getur falið þessa einu bilun á meðan það fjarlægir leiðina sem þarf fyrir næstu ytri beiðni.