Чаму ваш карпаратыўны проксі спрабуе развязаць імя сэрвісу Compose

Праграма выходзіць у інтэрнэт праз карпаратыўны проксі, але http://catalog:8080/ не працуе, і проксі не можа развязаць “catalog”. Гэты запыт, магчыма, ніколі не выкарыстоўваў унутраны DNS Docker.

HTTP-кліент можа выбраць свой проксі да ўсталявання прамога злучэння. Тады знешні проксі атрымлівае імя, сэнс якога існуе толькі ўсярэдзіне сеткі Compose.

1. Выкарыстоўвайце імя хоста ў запыце. Сэрвісы Compose даступныя па імені сэрвісу ў адпаведнай сетцы. Дадайце catalog у падтрыманую канфігурацыю абыходу кліента-спажыўца, замест таго каб жорстка прапісваць IP кантэйнера, які можа змяніцца.
2. Захавайце існуючыя выключэнні. Для кліента, які ўлічвае асяроддзе, аб’яднайце адпаведныя запісы са спісам арганізацыі:

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

Праверце фактычную бібліятэку або выканальны файл у вобразе на прадмет апрацоўкі рэгістру, версіі і граматыкі супастаўлення. Універсальнага парсера NO_PROXY няма. Праграма з іменем wget у невялікім вобразе не абавязана паводзіць сябе як GNU Wget.

Калі запыт выбраў прамую маршрутызацыю, праверце агульную сетку выклікальніка і сэрвісу, сэрвіс, які слухае, і порт кантэйнера. Апублікаваны порт хоста — гэта іншая канчатковая кропка. Абыход не можа дадаць адсутнае падключэнне да сеткі, гэтак жа як перастварэнне сеткі не можа навучыць знешні проксі прыватнаму імені Compose.

Захавайце задуманы падзел: унутраныя запыты выкарыстоўваюць свой унутраны шлях; знешнія запыты захоўваюць ухвалены проксі. Глабальнае адключэнне проксі можа схаваць гэтую адну няспраўнасць, але пазбавіць маршруту, патрэбнага для наступнага знешняга запыту.