Zakaj vaš podjetniški proxy poskuša razrešiti ime storitve Compose

Odjemalec HTTP lahko pošlje zahtevo za notranjo storitev svojemu konfiguriranemu proxyju, preden uporabi razreševanje imen storitev Docker. Dodajte namerne obvode za pravega odjemalca.

Aplikacija doseže internet prek svojega podjetniškega proxyja, vendar http://catalog:8080/ ne uspe in proxy ne more razrešiti »catalog«. Ta zahteva morda nikoli ni uporabila notranjega DNS Dockerja.

Odjemalec HTTP lahko izbere svoj proxy, preden vzpostavi neposredno povezavo. Zunanji proxy takrat prejme ime, katerega pomen obstaja samo znotraj omrežja Compose.

  1. V zahtevi uporabite ime gostitelja. Storitve Compose so v ustreznem omrežju najdljive po imenu storitve. Dodajte catalog v podprto konfiguracijo obvoda odjemalca, ki storitev uporablja, namesto da trdo zakodirate IP vsebnika, ki se lahko spremeni.
  2. Ohranite obstoječe izjeme. Za odjemalca, ki se zaveda okolja, združite ustrezne vnose s seznamom organizacije:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Preverite dejansko knjižnico ali izvršljivo datoteko v sliki glede obravnave velikih in malih črk, različice in ujemalne slovnice. Univerzalnega razčlenjevalnika NO_PROXY ni. Program z imenom wget v majhni sliki se mu ni treba obnašati kot GNU Wget.

Ko zahteva izbere neposredno usmerjanje, preverite skupno omrežje klicatelja in storitve, storitev, ki posluša, in vrata vsebnika. Objavljena vrata gostitelja so druga končna točka. Obvod ne more dodati manjkajoče omrežne povezave, tako kot ponovno ustvarjanje omrežja ne more zunanjega proxyja naučiti zasebnega imena Compose.

Ohranite predvideno ločitev: notranje zahteve uporabljajo svojo notranjo pot; zunanje zahteve ohranijo odobreni proxy. Globalna izključitev proxyja lahko skrije to eno napako, hkrati pa odstrani pot, potrebno za naslednjo zunanjo zahtevo.

Sorodni članki