Hvorfor bedriftsproxien din prøver å slå opp et Compose-tjenestenavn

Applikasjonen når internett gjennom bedriftsproxien sin, men http://catalog:8080/ mislykkes og proxien kan ikke slå opp «catalog». Den forespørselen har kanskje aldri brukt Dockers interne DNS.

En HTTP-klient kan velge proxien sin før den oppretter en direkte tilkobling. Den eksterne proxien mottar da et navn hvis betydning bare finnes inne i Compose-nettverket.

1. Bruk vertsnavnet i forespørselen. Compose-tjenester kan oppdages med tjenestenavn på riktig nettverk. Legg catalog til i den forbrukende klientens støttede omgåelseskonfigurasjon i stedet for å hardkode en container-IP som kan endres.
2. Behold eksisterende unntak. For en miljøbevisst klient, slå sammen de relevante oppføringene med organisasjonens liste:

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

Kontroller det faktiske biblioteket eller den kjørbare filen i imaget for store og små bokstaver, versjon og samsvarsgrammatikk. Det finnes ingen universell NO_PROXY-parser. Et program kalt wget i et lite image trenger ikke oppføre seg som GNU Wget.

Når forespørselen velger direkte ruting, kontroller det delte nettverket til kaller og tjeneste, den lyttende tjenesten og containerporten. En publisert vertsport er et annet endepunkt. En omgåelse kan ikke legge til en manglende nettverkstilkobling, slik gjenoppretting av et nettverk ikke kan lære en ekstern proxy et privat Compose-navn.

Behold den tiltenkte delingen: interne forespørsler bruker sin interne vei; eksterne forespørsler beholder den godkjente proxien. Å deaktivere proxien globalt kan skjule denne ene feilen samtidig som det fjerner ruten som trengs for neste eksterne forespørsel.