Varför din företagsproxy försöker slå upp ett Compose-tjänstenamn

Applikationen når internet via sin företagsproxy, men http://catalog:8080/ misslyckas och proxyn kan inte slå upp ”catalog”. Den förfrågan har kanske aldrig använt Dockers interna DNS.

En HTTP-klient kan välja sin proxy innan den upprättar en direkt anslutning. Den externa proxyn tar då emot ett namn vars betydelse bara finns inne i Compose-nätverket.

1. Använd värdnamnet i förfrågan. Compose-tjänster går att hitta via tjänstenamn i rätt nätverk. Lägg till catalog i den användande klientens stödda kringgåendekonfiguration i stället för att hårdkoda en container-IP som kan ändras.
2. Behåll befintliga undantag. För en miljömedveten klient, slå samman de relevanta posterna med organisationens lista:

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

Kontrollera det faktiska biblioteket eller den körbara filen i avbildningen för skiftlägeshantering, version och matchningsgrammatik. Det finns ingen universell NO_PROXY-parser. Ett program som heter wget i en liten avbildning behöver inte bete sig som GNU Wget.

När förfrågan väljer direkt routning, kontrollera den delade nätverket för anroparen och tjänsten, den lyssnande tjänsten och containerporten. En publicerad värdport är en annan slutpunkt. Ett kringgående kan inte lägga till en saknad nätverksanslutning, precis som att återskapa ett nätverk inte kan lära en extern proxy ett privat Compose-namn.

Behåll den avsedda uppdelningen: interna förfrågningar använder sin interna väg; externa förfrågningar behåller den godkända proxyn. Att inaktivera proxyn globalt kan dölja detta enda fel samtidigt som det tar bort vägen som behövs för nästa externa förfrågan.