Miért próbálja a vállalati proxy egy Compose-szolgáltatás nevét feloldani

Az alkalmazás a vállalati proxyján keresztül éri el az internetet, de a http://catalog:8080/ meghiúsul, és a proxy nem tudja feloldani a „catalog” nevet. Lehetséges, hogy ez a kérés soha nem használta a Docker belső DNS-ét.

Egy HTTP-kliens a közvetlen kapcsolat létrehozása előtt kiválaszthatja a proxyját. A külső proxy ekkor egy olyan nevet kap, amelynek jelentése csak a Compose-hálózaton belül létezik.

1. Használja a gazdagépnevet a kérésben. A Compose-szolgáltatások a megfelelő hálózaton szolgáltatásnév alapján felderíthetők. Adja hozzá a catalog elemet a fogyasztó kliens támogatott megkerülési konfigurációjához, ahelyett hogy keményen kódolná a változható konténer IP-címét.
2. Őrizze meg a meglévő kivételeket. Környezettudatos kliens esetén egyesítse a vonatkozó bejegyzéseket a szervezeti listával:

NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Ellenőrizze a lemezképben lévő tényleges könyvtárat vagy futtatható fájlt a kis- és nagybetűk kezelése, a verzió és az egyeztetési nyelvtan szempontjából. Nincs univerzális NO_PROXY elemző. Egy kis lemezképben lévő wget nevű programnak nem kell úgy viselkednie, mint a GNU Wget.

Miután a kérés a közvetlen útválasztást választja, ellenőrizze a hívó és a szolgáltatás közös hálózatát, a figyelő szolgáltatást és a konténer portját. A közzétett gazdagépport egy másik végpont. A megkerülés nem tud hozzáadni egy hiányzó hálózati csatlakozást, ahogy a hálózat újralétrehozása sem tud megtanítani egy külső proxynak egy privát Compose-nevet.

Tartsa meg a szándékolt felosztást: a belső kérések a belső útvonalukat használják; a külső kérések megtartják a jóváhagyott proxyt. A proxy globális letiltása elrejtheti ezt az egyetlen hibát, miközben eltávolítja a következő külső kéréshez szükséges útvonalat.