Miksi yrityksesi välityspalvelin yrittää selvittää Compose-palvelun nimeä

HTTP-asiakas voi lähettää sisäisen palvelupyynnön määritettyyn välityspalvelimeensa ennen Dockerin palvelunimien selvityksen käyttöä. Lisää tarkoitukselliset ohitukset oikealle asiakkaalle.

Sovellus saavuttaa internetin yrityksen välityspalvelimen kautta, mutta http://catalog:8080/ epäonnistuu eikä välityspalvelin pysty selvittämään nimeä “catalog”. Pyyntö ei ehkä koskaan käyttänyt Dockerin sisäistä DNS:ää.

HTTP-asiakas voi valita välityspalvelimensa ennen suoran yhteyden muodostamista. Silloin ulkoinen välityspalvelin saa nimen, jonka merkitys on vain Compose-verkon sisällä.

  1. Käytä pyynnössä isäntänimeä. Compose-palvelut ovat löydettävissä palvelunimellä asianmukaisessa verkossa. Lisää catalog kuluttavan asiakkaan tuettuun ohitusmääritykseen sen sijaan, että kovakoodaisit säilön IP-osoitteen, joka voi muuttua.
  2. Säilytä olemassa olevat poikkeukset. Ympäristötietoiselle asiakkaalle yhdistä asiaankuuluvat merkinnät organisaation luetteloon:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Tarkista kuvan varsinainen kirjasto tai suoritettava tiedosto kirjainkoon käsittelyn, version ja täsmäytyskieliopin osalta. Yleistä NO_PROXY-jäsennintä ei ole. Pienessä kuvassa wget-niminen ohjelma ei välttämättä käyttäydy kuin GNU Wget.

Kun pyyntö valitsee suoran reitityksen, tarkista kutsujan ja palvelun jaettu verkko, kuunteleva palvelu ja säilön portti. Julkaistu isäntäportti on toinen päätepiste. Ohitus ei voi lisätä puuttuvaa verkkoliitosta, samoin kuin verkon uudelleenluonti ei voi opettaa ulkoiselle välityspalvelimelle yksityistä Compose-nimeä.

Säilytä aiottu jako: sisäiset pyynnöt käyttävät sisäistä polkuaan; ulkoiset pyynnöt säilyttävät hyväksytyn välityspalvelimen. Välityspalvelimen poistaminen käytöstä maailmanlaajuisesti voi piilottaa tämän yhden virheen ja poistaa seuraavaan ulkoiseen pyyntöön tarvittavan reitin.

Aiheeseen liittyvät artikkelit