Per què el vostre proxy corporatiu intenta resoldre un nom de servei de Compose

L'aplicació arriba a internet a través del seu proxy corporatiu, però http://catalog:8080/ falla i el proxy no pot resoldre “catalog”. És possible que aquella sol·licitud no hagi utilitzat mai el DNS intern de Docker.

Un client HTTP pot triar el seu proxy abans de fer una connexió directa. Aleshores el proxy extern rep un nom el significat del qual només existeix dins de la xarxa de Compose.

1. Utilitzeu el nom d'amfitrió a la sol·licitud. Els serveis de Compose es poden descobrir pel nom de servei a la xarxa adequada. Afegiu catalog a la configuració d'exclusió compatible del client consumidor en lloc de codificar una IP de contenidor que pot canviar.
2. Conserveu les excepcions existents. Per a un client conscient de l'entorn, combineu les entrades rellevants amb la llista de l'organització:

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

Comproveu la biblioteca o l'executable real de la imatge pel que fa al tractament de majúscules i minúscules, la versió i la gramàtica de coincidència. No hi ha cap analitzador NO_PROXY universal. Un programa anomenat wget en una imatge petita no ha de comportar-se com GNU Wget.

Un cop la sol·licitud triï l'encaminament directe, comproveu la xarxa compartida del cridador i del servei, el servei que escolta i el port del contenidor. Un port d'amfitrió publicat és un altre punt final. Una exclusió no pot afegir una connexió de xarxa que falta, igual que recrear una xarxa no pot ensenyar a un proxy extern un nom privat de Compose.

Manteniu la divisió prevista: les sol·licituds internes utilitzen el seu camí intern; les sol·licituds externes conserven el proxy aprovat. Desactivar el proxy globalment pot amagar aquesta única fallada mentre elimina la ruta necessària per a la propera sol·licitud externa.