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

HTTP klijent može poslati zahtjev za internim servisom svom konfigurisanom proxyju prije nego što upotrijebi Dockerovo razrješavanje naziva servisa. 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 direktne veze. Vanjski proxy tada prima naziv čije značenje postoji samo unutar Compose mreže.

  1. Koristite ime hosta u zahtjevu. Compose servisi su dostupni po nazivu servisa 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 izuzetke. Za klijent koji poznaje okruženje, spojite relevantne unose s listom 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 uparivanja. 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 direktno usmjeravanje, provjerite zajedničku mrežu pozivatelja i servisa, servis koji sluša i port kontejnera. Objavljeni port hosta je druga krajnja tačka. Zaobilaženje ne može dodati nedostajuću mrežnu vezu, 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