Kodėl jūsų įmonės proxy bando išspręsti Compose paslaugos pavadinimą

HTTP klientas gali nusiųsti vidinės paslaugos užklausą savo sukonfigūruotam proxy, kol dar nenaudoja Docker paslaugų pavadinimų sprendimo. Pridėkite sąmoningus apėjimus tinkamam klientui.

Programa pasiekia internetą per savo įmonės proxy, bet http://catalog:8080/ nepavyksta ir proxy negali išspręsti „catalog“. Ta užklausa galbūt niekada nenaudojo Docker vidinio DNS.

HTTP klientas gali pasirinkti savo proxy prieš užmegzdamas tiesioginį ryšį. Tada išorinis proxy gauna vardą, kurio reikšmė egzistuoja tik Compose tinkle.

  1. Naudokite prieglobos vardą užklausoje. Compose paslaugos aptinkamos pagal paslaugos pavadinimą atitinkamame tinkle. Pridėkite catalog prie vartojančio kliento palaikomos apėjimo konfigūracijos, o ne kietai užkoduokite konteinerio IP, kuris gali pasikeisti.
  2. Išsaugokite esamas išimtis. Aplinką suvokiančiam klientui sujunkite atitinkamus įrašus su organizacijos sąrašu:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Patikrinkite tikrąją atvaizdžio biblioteką ar vykdomąjį failą dėl didžiųjų ir mažųjų raidžių tvarkymo, versijos ir atitikimo gramatikos. Nėra universalaus NO_PROXY analizatoriaus. Mažame atvaizde esanti programa pavadinimu wget neprivalo elgtis kaip GNU Wget.

Kai užklausa pasirenka tiesioginį maršrutizavimą, patikrinkite bendrą skambinančiojo ir paslaugos tinklą, klausančią paslaugą ir konteinerio prievadą. Paskelbtas prieglobos prievadas yra kitas galinis taškas. Apėjimas negali pridėti trūkstamo tinklo ryšio, kaip ir tinklo atkūrimas negali išmokyti išorinio proxy privataus Compose vardo.

Išlaikykite numatytą atskyrimą: vidinės užklausos naudoja savo vidinį kelią; išorinės užklausos išlaiko patvirtintą proxy. Visuotinis proxy išjungimas gali paslėpti šią vieną klaidą ir kartu pašalinti maršrutą, reikalingą kitai išorinei užklausai.

Susiję straipsniai