Naabot ng application ang internet sa pamamagitan ng corporate proxy nito, ngunit nabigo ang http://catalog:8080/ at hindi ma-resolve ng proxy ang “catalog”. Maaaring hindi kailanman ginamit ng kahilingang iyon ang panloob na DNS ng Docker.

Maaaring piliin ng isang HTTP client ang proxy nito bago gumawa ng direktang koneksyon. Natatanggap ng panlabas na proxy ang isang pangalan na ang kahulugan ay umiiral lamang sa loob ng network ng Compose.

  1. Gamitin ang hostname sa kahilingan. Matatagpuan ang mga serbisyo ng Compose sa pamamagitan ng pangalan ng serbisyo sa naaangkop na network. Idagdag ang catalog sa sinusuportahang bypass configuration ng client na gumagamit, sa halip na i-hard-code ang IP ng container na maaaring magbago.
  2. Panatilihin ang mga umiiral na eksepsiyon. Para sa client na may kamalayan sa kapaligiran, pagsamahin ang mga kaugnay na entry sa listahan ng organisasyon:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Suriin ang aktwal na library o executable sa image para sa paghawak ng case, bersyon at grammar ng pagtutugma. Walang unibersal na NO_PROXY parser. Ang programang pinangalanang wget sa isang maliit na image ay hindi kailangang kumilos tulad ng GNU Wget.

Kapag pinili ng kahilingan ang direktang routing, suriin ang shared network ng tumatawag at ng serbisyo, ang serbisyong nakikinig at ang port ng container. Ang nai-publish na host port ay isa pang endpoint. Hindi maaaring magdagdag ng nawawalang network attachment ang isang bypass, tulad ng hindi kayang turuan ng muling paggawa ng network ang isang panlabas na proxy ng pribadong pangalan ng Compose.

Panatilihin ang nilalayong paghahati: ang mga panloob na kahilingan ay gumagamit ng kanilang panloob na landas; ang mga panlabas na kahilingan ay nagpapanatili ng aprubadong proxy. Ang pag-disable ng proxy nang pandaigdigan ay maaaring magtago ng nag-iisang pagkabigo na ito habang inaalis ang rutang kailangan para sa susunod na panlabas na kahilingan.

Kaugnay na mga artikulo