L'objet JSON semble prometteur : une carte proxies avec une entrée default et des clés d'adresse supplémentaires. Il est tentant d'y placer un nom d'hôte de registre et de s'attendre à ce que les requêtes vers ce registre utilisent un autre proxy.

Ces clés identifient les démons Docker auxquels le client se connecte. Elles n'identifient pas les sites web qu'un conteneur demandera.

La configuration du client Docker peut fournir des variables d'environnement proxy aux nouveaux conteneurs et des arguments de build proxy aux nouveaux builds. Une entrée propre à un démon modifie cette configuration fournie pour le contexte de démon correspondant.

Elle ne configure pas la connexion proxy sortante du démon lui-même. Elle ne transforme pas non plus le client HTTP du conteneur en évaluateur PAC.

Si votre tâche est de garder un registre interne en direct pendant que le démon accède à d'autres services via un proxy, examinez la configuration proxy et de contournement prise en charge par le démon. Si l'application a besoin de proxys amont différents pour des destinations différentes, cette politique relève d'un agencement client ou de transfert approprié.

Avant de modifier la carte, notez quelle adresse la clé représente et quel processus effectue la requête qui échoue. Le même nom d'hôte peut apparaître dans une connexion à un démon, une URL de registre et une URL de proxy, mais ce sont trois rôles différents.

Articles similaires