Warum Ihr Unternehmensproxy versucht, einen Compose-Dienstnamen aufzulösen

Die Anwendung erreicht das Internet über ihren Unternehmensproxy, aber http://catalog:8080/ schlägt fehl und der Proxy kann „catalog“ nicht auflösen. Diese Anfrage hat möglicherweise nie das interne DNS von Docker verwendet.

Ein HTTP-Client kann seinen Proxy auswählen, bevor er eine direkte Verbindung herstellt. Der externe Proxy erhält dann einen Namen, dessen Bedeutung nur innerhalb des Compose-Netzwerks existiert.

1. Verwenden Sie den Hostnamen in der Anfrage. Compose-Dienste sind im entsprechenden Netzwerk über den Dienstnamen auffindbar. Fügen Sie catalog zur unterstützten Bypass-Konfiguration des nutzenden Clients hinzu, statt eine Container-IP fest zu kodieren, die sich ändern kann.
2. Bestehende Ausnahmen beibehalten. Bei einem umgebungsbewussten Client führen Sie die relevanten Einträge mit der Liste der Organisation zusammen:

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

Prüfen Sie die tatsächliche Bibliothek oder das ausführbare Programm im Image auf Groß- und Kleinschreibung, Version und Übereinstimmungsgrammatik. Es gibt keinen universellen NO_PROXY-Parser. Ein Programm namens wget in einem kleinen Image muss sich nicht wie GNU Wget verhalten.

Wenn die Anfrage direktes Routing wählt, prüfen Sie das gemeinsame Netzwerk von Aufrufer und Dienst, den lauschenden Dienst und den Container-Port. Ein veröffentlichter Host-Port ist ein anderer Endpunkt. Ein Bypass kann keine fehlende Netzwerkanbindung hinzufügen, genauso wie das Neuerstellen eines Netzwerks einem externen Proxy keinen privaten Compose-Namen beibringen kann.

Behalten Sie die beabsichtigte Trennung bei: Interne Anfragen nutzen ihren internen Pfad; externe Anfragen behalten den genehmigten Proxy. Ein globales Deaktivieren des Proxys kann diesen einen Fehler verbergen und gleichzeitig die für die nächste externe Anfrage benötigte Route entfernen.