Atteindre un proxy hôte depuis un conteneur Docker en bridge

Choisissez une adresse proxy joignable depuis le conteneur et distinguez un point public d’un proxy exécuté sur l’hôte Docker.

Dans un conteneur ordinaire en réseau bridge, 127.0.0.1 est l’adresse de bouclage propre au conteneur. Un proxy écoutant sur localhost de votre portable n’écoute pas automatiquement dans chaque conteneur.

Cela explique une différence fréquente : la même URL proxy fonctionne dans le terminal de l’hôte, mais donne une connexion refusée dans le conteneur. L’adresse désigne un point réseau différent dans chaque contexte.

Un proxy public peut être utilisé directement

Si le point choisi dans un service ou la liste de proxys HTTP est réellement une IP publique joignable, fournissez cette adresse à l’application au lieu de la remplacer par localhost :

docker run --rm \
  -e HTTP_PROXY=http://203.0.113.10:8080 \
  -e HTTPS_PROXY=http://203.0.113.10:8080 \
  your-image

Remplacez l’adresse documentaire et l’image. Le programme dans l’image doit toujours prendre en charge ces variables ; Docker ne transforme pas chaque socket en requête proxy parce que les variables existent.

Si le proxy s’exécute sur l’hôte Docker

Docker Desktop fournit host.docker.internal pour atteindre l’adresse interne de l’hôte. Dans une configuration Engine native compatible, une correspondance d’hôte peut fournir ce nom conventionnel :

docker run --rm \
  --add-host host.docker.internal=host-gateway \
  -e HTTP_PROXY=http://host.docker.internal:8080 \
  -e HTTPS_PROXY=http://host.docker.internal:8080 \
  your-image

Cela modifie la résolution de noms, pas le transfert de ports. Sous Linux natif, un service lié seulement au bouclage de l’hôte peut rester inaccessible par l’adresse bridge de l’hôte. L’écoute, le pare-feu et la route du conteneur doivent autoriser la connexion. Si vous changez l’écoute, limitez-la aux clients nécessaires au lieu de créer un proxy ouvert sans authentification.

Tester depuis le même endroit que l’application

Un résultat curl sur l’hôte ne teste que sa route. Effectuez la requête depuis l’environnement du conteneur et vérifiez qu’elle atteint le point prévu.

« Hôte » désigne aussi la machine exécutant Docker Engine. Avec un Engine distant, ce n’est pas forcément votre portable. Une IP de bouclage copiée d’une application de bureau locale a donc particulièrement peu de chances de fonctionner sans changement sur un builder ou serveur distant.

Séparez les problèmes de récupération d’image : le démon télécharge l’image avant que l’application puisse utiliser l’environnement ci-dessus.

Articles similaires