Compatibilité de NO_PROXY entre curl, .NET et les conteneurs
Transformez une politique de routage direct partagée en configuration propre à chaque client à l'aide d'un petit ensemble de destinations représentatives.
Une équipe place une chaîne d'exclusion dans un fichier d'environnement partagé. curl passe en direct, une autre application utilise le proxy, et un conteneur se comporte encore différemment. Le fichier partagé distribuait les mêmes caractères. Mais il ne distribuait pas un analyseur commun.
L'objet durable est la politique : quelles destinations doivent être directes, et dans quelles conditions ? Gardez-la séparée de la chaîne dont chaque programme a besoin.
Écrivez d'abord les routes attendues
Utilisez des adresses représentatives, y compris les limites et pas seulement les succès faciles :
| Forme de la destination | Question pour le responsable de la politique |
|---|---|
| Domaine parent | Faut-il l'exclure, ou seulement ses enfants ? |
| Un sous-domaine | Hérite-t-il de la même route ? |
| Une IP privée littérale | Cette adresse est-elle joignable directement depuis ce client ? |
| Le même service sous un nom d'hôte | Les requêtes par nom et par adresse doivent-elles concorder ? |
| Un autre port de service | L'exception couvre-t-elle l'hôte ou un seul écouteur ? |
Identifiez ensuite les consommateurs : le démon qui récupère une image, le programme dans le conteneur, une bibliothèque HTTP de langage et un navigateur interactif peuvent tous être des entrées distinctes. Une configuration de proxy client Docker peut renseigner les valeurs d'environnement du conteneur sans que chaque client à l'intérieur doive implémenter les mêmes règles de correspondance.
Traduisez au lieu de copier aveuglément
Un exemple documenté de différence réelle est la limite du domaine parent. L'exclusion de domaine de curl couvre le domaine nommé et les enfants correspondants. La politique d'environnement de .NET distingue le nom nu de la forme de sous-domaine à point initial. Une règle universelle consistant à toujours ajouter un point initial ne peut pas exprimer les deux politiques de manière fiable.
La prise en charge des plages IP dépend aussi du consommateur et de sa version. Une machine dotée d'un nouveau curl autonome peut toujours exécuter une application liée à un libcurl plus ancien, ou un client utilisant une bibliothèque entièrement différente. La version du système d'exploitation n'est pas un inventaire complet des clients.
Pour chaque consommateur, notez son interface de configuration prise en charge et l'expression la plus petite des routes prévues. Une courte liste d'hôtes explicite peut valoir mieux qu'un motif astucieux dont personne ne peut expliquer le sens.
Gardez les preuves de configuration séparées des preuves de connexion
Un réglage analysé ou une API de décisions de routage peut montrer ce que le programme a choisi. Le résultat d'une requête montre ensuite si cette route était utilisable. Dans .NET, HttpClient.DefaultProxy.IsBypassed fournit cette vérification côté configuration lorsque le proxy par défaut est la politique utilisée. Ne diagnostiquez pas un service direct inaccessible comme une défaillance de l'analyseur d'exclusion simplement parce que la requête a expiré.
Conservez les destinations limites lors de la mise à jour d'un client ou d'une image de base. Elles rendent visibles les futurs changements de compatibilité sans que toute l'équipe doive redécouvrir pourquoi le fichier contient deux entrées de domaine similaires.