Zašto vaš korporativni proxy pokušava razriješiti naziv Compose usluge

HTTP klijent može poslati zahtjev za internom uslugom svom konfiguriranom proxyju prije nego što upotrijebi Dockerovo razrješavanje naziva usluga. Dodajte namjerna zaobilaženja za pravi klijent.

Aplikacija dolazi na internet preko svog korporativnog proxyja, ali http://catalog:8080/ ne uspijeva i proxy ne može razriješiti “catalog”. Taj zahtjev možda nikada nije koristio Dockerov interni DNS.

HTTP klijent može odabrati svoj proxy prije uspostavljanja izravne veze. Vanjski proxy tada prima naziv čije značenje postoji samo unutar Compose mreže.

  1. Koristite naziv hosta u zahtjevu. Compose usluge dostupne su po nazivu usluge na odgovarajućoj mreži. Dodajte catalog u podržanu konfiguraciju zaobilaženja klijenta koji ga koristi, umjesto da tvrdo kodirate IP kontejnera koji se može promijeniti.
  2. Sačuvajte postojeće iznimke. Za klijent koji poznaje okruženje, spojite relevantne unose s popisom organizacije:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Provjerite stvarnu biblioteku ili izvršnu datoteku u slici u pogledu rukovanja velikim i malim slovima, verzije i gramatike podudaranja. Ne postoji univerzalni parser NO_PROXY. Program po imenu wget u maloj slici ne mora se ponašati kao GNU Wget.

Nakon što zahtjev odabere izravno usmjeravanje, provjerite zajedničku mrežu pozivatelja i usluge, uslugu koja sluša i port kontejnera. Objavljeni port hosta druga je krajnja točka. Zaobilaženje ne može dodati mrežni priključak koji nedostaje, kao što ni ponovno stvaranje mreže ne može vanjski proxy naučiti privatni Compose naziv.

Zadržite predviđenu podjelu: interni zahtjevi koriste svoju internu putanju; vanjski zahtjevi zadržavaju odobreni proxy. Globalno onemogućavanje proxyja može sakriti ovaj jedan kvar dok uklanja rutu potrebnu za sljedeći vanjski zahtjev.

Povezani članci