NO_PROXY-kompatibilitás curl, .NET és konténerek között
Alakítson át egy közös közvetlen útválasztási szabályzatot ügyfélspecifikus konfigurációvá néhány reprezentatív cél használatával.
Egy csapat egyetlen megkerülési karakterláncot tesz egy közös környezeti fájlba. A curl közvetlenül megy, egy másik alkalmazás a proxyt használja, a konténer pedig megint másként viselkedik. A közös fájl ugyanazokat a karaktereket terjesztette. De nem terjesztett egy közös elemzőt.
A tartós objektum a szabályzat: mely célok legyenek közvetlenek, és milyen feltételek mellett? Tartsa ezt elkülönítve attól a karakterlánctól, amelyre minden programnak szüksége van.
Először írja le a várt útvonalakat
Használjon reprezentatív címeket, beleértve a határokat is, nem csak a könnyű sikereket:
| A cél alakja | Kérdés a szabályzat tulajdonosához |
|---|---|
| Szülő domain | Meg kell-e kerülni, vagy csak a gyermekeit? |
| Egy aldomain | Örökli ugyanazt az útvonalat? |
| Szó szerinti privát IP | Elérhető-e ez a cím közvetlenül erről az ügyfélről? |
| Ugyanaz a szolgáltatás hosztnév alatt | Egyezniük kell a név alapú és a cím alapú kéréseknek? |
| Egy másik szolgáltatási port | A kivétel a hosztot vagy egyetlen figyelőt fed le? |
Ezután azonosítsa a fogyasztókat: a képet lehúzó démon, a konténeren belüli program, egy nyelvi HTTP-könyvtár és egy interaktív böngésző mind külön bejegyzés lehet. Egy Docker-ügyfél proxykonfigurációja kitöltheti a konténer környezeti értékeit anélkül, hogy minden belső ügyfélnek ugyanazokat az egyeztetési szabályokat kellene megvalósítania.
Fordítson a vak másolás helyett
Egy dokumentált példa a valódi különbségre a szülő domain határa. A curl domainkizárása a megnevezett domaint és az egyező gyermekeket fedi le. A .NET környezeti szabályzata megkülönbözteti a csupasz nevet a vezető ponttal ellátott aldomain-formától. Egy univerzális szabály, hogy mindig adjunk hozzá vezető pontot, nem tudja megbízhatóan kifejezni mindkét szabályzatot.
Az IP-tartományok támogatása is a fogyasztótól és annak verziójától függ. Egy új önálló curl-lel rendelkező gép még mindig futtathat egy régebbi libcurlhez linkelt alkalmazást, vagy egy teljesen más könyvtárat használó ügyfelet. Az operációs rendszer kiadása nem teljes ügyféllista.
Minden fogyasztóhoz rögzítse a támogatott konfigurációs felületet és a tervezett útvonalak legkisebb kifejezését. Egy rövid, egyértelmű hosztlista jobb lehet egy olyan okos mintánál, amelynek jelentését senki sem tudja megmagyarázni.
Tartsa a konfigurációs bizonyítékokat elkülönítve a kapcsolati bizonyítékoktól
Egy elemzett beállítás vagy egy útválasztási döntési API megmutathatja, mit választott a program. Egy kérés eredménye aztán megmutatja, hogy az az útvonal használható volt-e. A .NET-ben, HttpClient.DefaultProxy.IsBypassed biztosítja ezt a konfigurációs oldali ellenőrzést, amikor az alapértelmezett proxy a használt szabályzat. Ne diagnosztizáljon egy elérhetetlen közvetlen szolgáltatást megkerülési elemző hibájaként csak azért, mert a kérés időtúllépésbe futott.
Őrizze meg a határcélokat egy ügyfél vagy egy alapkép frissítésekor. Láthatóvá teszik a jövőbeli kompatibilitási változásokat anélkül, hogy az egész csapatnak újra fel kellene fedeznie, miért tartalmaz a fájl két hasonló domainbejegyzést.