Attribuer un proxy différent à certains hôtes dans Yarn moderne
Utilisez les paramètres réseau par hôte de Yarn moderne lorsqu'une source de paquets a besoin d'un intermédiaire différent de celui par défaut.
Un proxy général ne convient pas forcément à toutes les sources de paquets. Yarn moderne prend en charge des paramètres réseau par nom d'hôte, ce qui permet à un hôte choisi d'emprunter une route différente de celle par défaut.
Par exemple, un projet peut conserver une route générale et en choisir une autre pour un registre interne :
httpsProxy: "http://203.0.113.10:8080"
networkSettings:
"registry.example.internal":
httpsProxy: "http://203.0.113.20:8080"Les deux adresses sont des exemples fictifs. Pour une route générale vers des sources de paquets publiques, la liste de proxys HTTP propose des candidats lorsque les proxys publics sont autorisés. Gardez la surcharge du registre interne sur son proxy approuvé. Placez la configuration dans le fichier .yarnrc.yml approprié pour une version moderne de Yarn. Cet exemple sélectionne deux proxys ; il n'indique pas que l'hôte interne doit se connecter directement.
Correspondre au nom d'hôte demandé
L'entrée networkSettings s'applique à un motif de nom d'hôte, pas à une portée de paquet ni à un chemin d'URL arbitraire. Gardez une règle mono-hôte exacte lorsque c'est bien ce que vous voulez dire. Un joker n'est utile que si vous souhaitez réellement que les hôtes supplémentaires partagent la configuration.
Une portée de paquet et un nom d'hôte réseau sont deux sélecteurs différents. Un paquet à portée peut être récupéré depuis un registre dont l'hôte est partagé avec d'autres paquets, tandis qu'un artefact redirigé peut provenir d'un tout autre nom d'hôte.
Suivre le chemin de téléchargement complet
Si les métadonnées utilisent un hôte et le téléchargement de l'archive un autre, ils peuvent correspondre à des paramètres réseau différents. Notez l'URL qui échoue réellement avant d'élargir la règle. « Le registre fonctionnait » n'établit pas quelle route une requête ultérieure a choisie.
Les paramètres par hôte de Yarn peuvent aussi inclure l'AC et d'autres paramètres TLS. Gardez ces décisions séparées : choisir une adresse de proxy ne fournit pas à lui seul la confiance nécessaire à un environnement d'inspection.
Rendre la surcharge visible
Inspectez la configuration effective du projet avec les outils pris en charge par sa version de Yarn, puis testez la requête souhaitée. Évitez de partager un export complet de configuration s'il contient des identifiants.
Cette fonctionnalité est utile lorsque les hôtes exigent réellement des routes différentes. Si chaque requête doit utiliser le même point de terminaison, un seul réglage général est plus simple à maintenir qu'une liste croissante de surcharges de nom d'hôte identiques.