NO_PROXY ühilduvus curl-i, .NET-i ja konteinerite vahel
Muutke ühine otsemarsruutimise poliitika kliendipõhiseks konfiguratsiooniks, kasutades väikest hulka esinduslikke sihtkohti.
Meeskond paneb ühe möödasõidu stringi ühisesse keskkonnafaili. curl läheb otse, teine rakendus kasutab puhverserverit ja konteiner käitub jälle teisiti. Ühine fail jagas samu märke. Kuid see ei jaganud üht ühist parserit.
Püsiv objekt on poliitika: millised sihtkohad peaksid olema otsesed ja millistel tingimustel? Hoidke see eraldi stringist, mida iga programm vajab.
Kirjutage esmalt oodatavad marsruudid
Kasutage esinduslikke aadresse, sealhulgas piire, mitte ainult lihtsaid õnnestumisi:
| Sihtkoha kuju | Küsimus poliitika omanikule |
|---|---|
| Ülemdomeen | Kas see tuleb vahele jätta või ainult selle alamdomeenid? |
| Alamdomeen | Kas see pärib sama marsruudi? |
| Literaalne privaatne IP | Kas see aadress on sellest kliendist otse kättesaadav? |
| Sama teenus hostinime all | Kas nimepõhised ja aadressipõhised päringud peaksid kokku langema? |
| Teine teenuseport | Kas erand hõlmab hosti või ühte kuulajat? |
Seejärel tuvastage tarbijad: pilti tõmbav deemon, konteineris olev programm, keele HTTP-teek ja interaktiivne brauser võivad kõik olla eraldi kirjed. Dockeri kliendi puhverserveri konfiguratsioon saab konteineri keskkonnaväärtusi täita, ilma et iga klient sees peaks rakendama samu vastendusreegleid.
Tõlkige, selle asemel et pimesi kopeerida
Üks dokumenteeritud näide tegelikust erinevusest on ülemdomeeni piir. curl-i domeeni välistamine hõlmab nimetatud domeeni ja sobivaid alamdomeene. .NET-i keskkonnapoliitika eristab paljast nime algpunktiga alamdomeeni vormist. Universaalne reegel alati algpunkt lisada ei suuda mõlemat poliitikat usaldusväärselt väljendada.
IP-vahemike tugi sõltub samuti tarbijast ja selle versioonist. Uue iseseisva curl-iga masin võib siiski käitada rakendust, mis on lingitud vanema libcurl-iga, või klienti, mis kasutab hoopis teist teeki. Operatsioonisüsteemi väljaanne ei ole täielik klientide loend.
Iga tarbija jaoks registreerige selle toetatud konfiguratsiooniliides ja kavandatud marsruutide väikseim väljendus. Lühike selgesõnaline hostide loend võib olla parem kui nutikas muster, mille tähendust keegi seletada ei oska.
Hoidke konfiguratsioonitõendid ühendusetõenditest eraldi
Parsitud säte või marsruutimisotsuste API võib näidata, mille programm valis. Päringu tulemus näitab seejärel, kas see marsruut oli kasutatav. .NET-is, HttpClient.DefaultProxy.IsBypassed pakub seda konfiguratsioonipoolset kontrolli, kui vaikimisi puhverserver on kasutatav poliitika. Ärge diagnoosige kättesaamatut otsest teenust möödasõidu parseri tõrkena ainult seetõttu, et päring aegus.
Säilitage piirisihtkohad kliendi või baaspildi uuendamisel. Need teevad tulevased ühilduvusmuudatused nähtavaks, ilma et kogu meeskond peaks uuesti avastama, miks fail sisaldab kahte sarnast domeenikirjet.