De ce proxy-ul companiei tale încearcă să rezolve un nume de serviciu Compose

Un client HTTP poate trimite o cerere către un serviciu intern proxy-ului configurat înainte de a folosi rezolvarea numelor de servicii Docker. Adaugă ocoliri deliberate pentru clientul potrivit.

Aplicația ajunge la internet prin proxy-ul companiei, dar http://catalog:8080/ eșuează, iar proxy-ul nu poate rezolva „catalog”. Este posibil ca acea cerere să nu fi folosit niciodată DNS-ul intern al Docker.

Un client HTTP poate selecta proxy-ul înainte de a stabili o conexiune directă. Proxy-ul extern primește atunci un nume a cărui semnificație există doar în rețeaua Compose.

  1. Folosește numele de gazdă în cerere. Serviciile Compose pot fi descoperite după numele serviciului în rețeaua potrivită. Adaugă catalog la configurația de ocolire acceptată de clientul consumator în loc să codifici rigid un IP de container care se poate schimba.
  2. Păstrează excepțiile existente. Pentru un client conștient de mediu, îmbină intrările relevante cu lista organizației:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Verifică biblioteca sau executabilul real din imagine pentru tratarea majusculelor și minusculelor, versiune și gramatica de potrivire. Nu există un parser NO_PROXY universal. Un program numit wget într-o imagine mică nu trebuie să se comporte ca GNU Wget.

Odată ce cererea alege rutarea directă, verifică rețeaua comună a apelantului și a serviciului, serviciul care ascultă și portul containerului. Un port de gazdă publicat este un alt punct final. O ocolire nu poate adăuga o conexiune de rețea lipsă, la fel cum recrearea unei rețele nu poate învăța un proxy extern un nume Compose privat.

Păstrează separarea dorită: cererile interne își folosesc calea internă; cererile externe păstrează proxy-ul aprobat. Dezactivarea globală a proxy-ului poate ascunde această singură defecțiune, eliminând în același timp ruta necesară pentru următoarea cerere externă.

Articole similare