Zergatik zure proxy korporatiboa Compose zerbitzu-izen bat ebazten saiatzen ari da

HTTP bezero batek barne zerbitzu-eskaera bidal diezaioke bere proxy konfiguratuari, Dockerren zerbitzu-izenaren ebazpena erabili aurretik. Gehitu nahita egindako saihestekoak bezero egokirako.

Aplikazioa internet-era iristen da bere proxy korporatiboaren bidez, baina http://catalog:8080/ huts egiten du eta proxyak ezin du “catalog” ebatzi. Baliteke eskaera horrek inoiz erabili ez izana Dockerren barne DNSa.

HTTP bezero batek bere proxya aukeratu dezake konexio zuzena egin aurretik. Orduan kanpoko proxyak Compose sarearen barruan soilik existitzen den esanahia duen izen bat jasotzen du.

  1. Erabili ostalari-izena eskaeran. Compose zerbitzuak zerbitzu-izenaren bidez aurki daitezke sare egokian. Gehitu catalog bezero kontsumitzailearen saihesteko konfigurazio onartuan, alda daitekeen edukiontzi IP bat gogor kodetu beharrean.
  2. Mantendu lehendik dauden salbuespenak. Inguruneaz jabetzen den bezero baterako, batu dagokion sarrerak erakundearen zerrendarekin:
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

Egiaztatu irudiko benetako liburutegia edo exekutagarria maiuskula/minuskulen trataerari, bertsioari eta bat-etortze gramatikari dagokionez. Ez dago NO_PROXY analizatzailerik unibertsalik. Irudi txiki bateko wget izeneko programak ez du zertan GNU Wget bezala jokatu.

Eskaerak bideratze zuzena aukeratu ondoren, egiaztatu deitzailearen eta zerbitzuaren sare partekatua, entzuten ari den zerbitzua eta edukiontziaren portua. Argitaratutako ostalari-portua beste mutur bat da. Saihestekoak ezin du falta den sare-konexiorik gehitu, sare bat berreraikitzeak kanpoko proxyari Compose izen pribatu bat irakatsi ezin dion bezala.

Mantendu aurreikusitako banaketa: barne eskaerek beren barne bidea erabiltzen dute; kanpoko eskaerek onartutako proxya mantentzen dute. Proxya modu globalean desgaitzeak hutsegite hau ezkuta dezake, hurrengo kanpoko eskaerarako behar den bidea kenduz.

Erlazionatutako artikuluak