Kvifor bedriftsproxien din prøver å slå opp eit Compose-tenestenamn

Applikasjonen når internett gjennom bedriftsproxien sin, men http://catalog:8080/ mislukkast og proxien kan ikkje slå opp «catalog». Den førespurnaden har kanskje aldri brukt den interne DNS-en til Docker.

Ein HTTP-klient kan velja proxien sin før han opprettar ei direkte tilkopling. Den eksterne proxien får då eit namn som berre har tyding inne i Compose-nettverket.

1. Bruk vertsnamnet i førespurnaden. Compose-tenester kan finnast med tenestenamn på rett nettverk. Legg catalog til i den støtta omgåingskonfigurasjonen til den forbrukande klienten i staden for å hardkoda ein container-IP som kan endra seg.
2. Hald på eksisterande unntak. For ein miljømedviten klient, slå saman dei relevante oppføringane med lista til organisasjonen:

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

Kontroller det faktiske biblioteket eller den køyrbare fila i imaget for store og små bokstavar, versjon og samsvarsgrammatikk. Det finst ingen universell NO_PROXY-parser. Eit program kalla wget i eit lite image treng ikkje oppføra seg som GNU Wget.

Når førespurnaden vel direkte ruting, kontroller det delte nettverket til kallaren og tenesta, den lyttande tenesta og containerporten. Ein publisert vertsport er eit anna endepunkt. Ei omgåing kan ikkje leggja til ei manglande nettverkstilkopling, slik gjenoppretting av eit nettverk ikkje kan læra ein ekstern proxy eit privat Compose-namn.

Hald på den tiltenkte delinga: interne førespurnader brukar den interne vegen sin; eksterne førespurnader held på den godkjende proxien. Å slå av proxien globalt kan skjula denne eine feilen samstundes som det fjernar ruta som trengst for neste eksterne førespurnad.