Compatibilità di NO_PROXY tra curl, .NET e container
Trasformate una politica condivisa di routing diretto in una configurazione specifica per il client usando un piccolo insieme di destinazioni rappresentative.
Un team inserisce una stringa di bypass in un file di ambiente condiviso. curl va diretto, un'altra applicazione usa il proxy e un container si comporta di nuovo diversamente. Il file condiviso distribuiva gli stessi caratteri. Ma non distribuiva un parser condiviso.
L'oggetto duraturo è la politica: quali destinazioni devono essere dirette e a quali condizioni? Tenetela separata dalla stringa che serve a ciascun programma.
Scrivete prima le route attese
Usate indirizzi rappresentativi, inclusi i confini e non solo i successi facili:
| Forma della destinazione | Domanda per il responsabile della politica |
|---|---|
| Dominio padre | Va aggirato, o solo i suoi figli? |
| Un sottodominio | Eredita la stessa route? |
| Un IP privato letterale | Quell'indirizzo è raggiungibile direttamente da questo client? |
| Lo stesso servizio sotto un nome host | Le richieste basate sul nome e quelle basate sull'indirizzo devono coincidere? |
| Un'altra porta del servizio | L'eccezione copre l'host o un solo listener? |
Poi identificate i consumatori: il demone che scarica un'immagine, il programma dentro il container, una libreria HTTP di un linguaggio e un browser interattivo possono essere tutte voci separate. Una configurazione proxy del client Docker può popolare i valori di ambiente del container senza che ogni client al suo interno debba implementare le stesse regole di corrispondenza.
Traducete invece di copiare alla cieca
Un esempio documentato di una differenza reale è il confine del dominio padre. L'esclusione del dominio di curl copre il dominio nominato e i figli corrispondenti. La politica di ambiente di .NET distingue il nome nudo dalla forma di sottodominio con punto iniziale. Una regola universale di aggiungere sempre un punto iniziale non può esprimere entrambe le politiche in modo affidabile.
Il supporto degli intervalli IP dipende anche dal consumatore e dalla sua versione. Una macchina con un curl autonomo nuovo può ancora eseguire un'applicazione collegata a un libcurl più vecchio, o un client che usa una libreria completamente diversa. La versione del sistema operativo non è un inventario completo dei client.
Per ogni consumatore, annotate l'interfaccia di configurazione supportata e l'espressione più piccola delle route previste. Un breve elenco esplicito di host può essere migliore di un modello astuto di cui nessuno sa spiegare il significato.
Tenete le prove di configurazione separate dalle prove di connessione
Un'impostazione analizzata o un'API di decisioni di routing può mostrare cosa ha scelto il programma. L'esito di una richiesta mostra poi se quella route era utilizzabile. In .NET, HttpClient.DefaultProxy.IsBypassed fornisce quel controllo lato configurazione quando il proxy predefinito è la politica in uso. Non diagnosticate un servizio diretto irraggiungibile come un guasto del parser di bypass solo perché la richiesta è scaduta.
Conservate le destinazioni di confine quando aggiornate un client o un'immagine di base. Rendono visibili i futuri cambiamenti di compatibilità senza che l'intero team debba riscoprire perché il file contiene due voci di dominio simili.