NO_PROXY-kompatibilitet på tværs af curl, .NET og containere
Omdan en delt politik for direkte routing til klientspecifik konfiguration ved hjælp af et lille sæt repræsentative destinationer.
Et team lægger én omgåelsesstreng i en delt miljøfil. curl går direkte, en anden applikation bruger proxyen, og en container opfører sig igen anderledes. Den delte fil distribuerede de samme tegn. Men den distribuerede ikke én delt parser.
Det varige objekt er politikken: hvilke destinationer skal være direkte, og under hvilke betingelser? Hold det adskilt fra den streng, hvert program har brug for.
Skriv de forventede ruter først
Brug repræsentative adresser, inklusive grænser og ikke kun nemme succeser:
| Destinationsform | Spørgsmål til politikkens ejer |
|---|---|
| Overordnet domæne | Skal det omgås, eller kun dets børn? |
| Et underdomæne | Arver det samme rute? |
| En litteral privat IP | Er den adresse direkte tilgængelig fra denne klient? |
| Samme tjeneste under et værtsnavn | Skal navnebaserede og adressebaserede anmodninger stemme overens? |
| En anden tjenesteport | Dækker undtagelsen værten eller én lytter? |
Identificer derefter forbrugerne: daemonen, der henter et image, programmet inde i containeren, et sprogligt HTTP-bibliotek og en interaktiv browser kan alle være separate poster. En Docker-klientproxykonfiguration kan udfylde containerens miljøværdier uden at hver klient indeni skal implementere de samme matchningsregler.
Oversæt i stedet for at kopiere blindt
Et dokumenteret eksempel på en reel forskel er grænsen for det overordnede domæne. curls domæneudelukkelse dækker det navngivne domæne og matchende børn. .NETs miljøpolitik skelner mellem det nøgne navn og underdomæneformen med indledende punktum. En universel regel om altid at tilføje et indledende punktum kan ikke udtrykke begge politikker pålideligt.
Understøttelse af IP-intervaller afhænger også af forbrugeren og dens version. En maskine med en ny selvstændig curl kan stadig køre en applikation, der er linket til en ældre libcurl, eller en klient, der bruger et helt andet bibliotek. Operativsystemets udgivelse er ikke en fuldstændig klientfortegnelse.
For hver forbruger skal du registrere dens understøttede konfigurationsgrænseflade og det mindste udtryk for de tilsigtede ruter. En kort eksplicit værtsliste kan være bedre end et smart mønster, hvis betydning ingen kan forklare.
Hold konfigurationsbevis adskilt fra forbindelsesbevis
En parset indstilling eller API for routingbeslutninger kan vise, hvad programmet valgte. Et anmodningsresultat viser derefter, om den rute var brugbar. I .NET, HttpClient.DefaultProxy.IsBypassed giver den konfigurationssidekontrol, når standardproxyen er den anvendte politik. Diagnosticer ikke en utilgængelig direkte tjeneste som en fejl i omgåelsesparseren, blot fordi anmodningen timede ud.
Behold grænsedestinationerne, når du opdaterer en klient eller et basisimage. De gør fremtidige kompatibilitetsændringer synlige uden at kræve, at hele teamet genopdager, hvorfor filen indeholder to enslydende domæneposter.