Miks teie ettevõtte puhverserver üritab Compose'i teenuse nime lahendada

HTTP-klient võib saata sisemise teenusetaotluse oma konfigureeritud puhverserverile enne Dockeri teenusenimede lahenduse kasutamist. Lisage õigele kliendile teadlikud möödaviigud.

Rakendus pääseb internetti oma ettevõtte puhverserveri kaudu, kuid http://catalog:8080/ ei õnnestu ja puhverserver ei suuda “catalog” lahendada. Võimalik, et see taotlus ei kasutanud kunagi Dockeri sisemist DNS-i.

HTTP-klient võib valida oma puhverserveri enne otsese ühenduse loomist. Seejärel saab väline puhverserver nime, mille tähendus on ainult Compose'i võrgu sees.

  1. Kasutage taotluses hostinime. Compose'i teenused on vastavas võrgus leitavad teenuse nime järgi. Lisage catalog tarbiva kliendi toetatud möödaviigu konfiguratsiooni, selle asemel et kõvasti kodeerida konteineri IP-d, mis võib muutuda.
  2. Säilitage olemasolevad erandid. Keskkonda arvestava kliendi puhul ühendage asjakohased kirjed organisatsiooni loendiga:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Kontrollige pildis olevat tegelikku teeki või käivitatavat faili suur- ja väiketähtede käsitlemise, versiooni ja vastavusgrammatika osas. Universaalset NO_PROXY parserit ei ole. Väikeses pildis wget-nimeline programm ei pea käituma nagu GNU Wget.

Kui taotlus valib otsese marsruutimise, kontrollige kutsuja ja teenuse jagatud võrku, kuulavat teenust ja konteineri porti. Avaldatud hosti port on teine lõpp-punkt. Möödaviik ei saa lisada puuduvat võrguühendust, nii nagu võrgu uuesti loomine ei saa õpetada välisele puhverserverile privaatset Compose'i nime.

Säilitage kavandatud jaotus: sisemised taotlused kasutavad oma sisemist teed; välised taotlused säilitavad heakskiidetud puhverserveri. Puhverserveri globaalne keelamine võib selle ühe tõrke varjata, eemaldades samal ajal järgmise välise taotluse jaoks vajaliku marsruudi.

Seotud artiklid