Podman pasta : joindre un proxy loopback de l'hôte depuis un conteneur sans root

Utilisez le transfert TCP de pasta du namespace vers l'hôte pour un proxy loopback existant, et distinguez-le de la publication d'un port de conteneur.

Le 127.0.0.1:8118 de l'hôte et le 127.0.0.1:8118 du conteneur sont normalement des points de terminaison loopback distincts. Le passage d'une variable de proxy dans un conteneur sans root ne relie pas ces interfaces loopback.

Dans un déploiement Podman utilisant pasta, son transfert TCP du namespace vers l'hôte peut exposer le port d'hôte voulu à l'intérieur du namespace :

podman run --network=pasta:-T,8118 \
  --env http_proxy=http://127.0.0.1:8118 \
  --env https_proxy=http://127.0.0.1:8118 \
  existing-image application-command

Utilisez l'image et la commande existantes de l'application. L'exemple suppose un proxy HTTP fonctionnel côté hôte sur le port 8118 et une version de Podman/pasta prenant en charge l'option de transfert indiquée.

Le -T majuscule de pasta transfère du namespace cible vers le namespace de l'hôte. Le -t minuscule et --publish de Podman visent la direction opposée. Publier le port de conteneur 8118 ne rend donc pas, à lui seul, le proxy de l'hôte accessible au conteneur.

Podman désactive par défaut le transfert automatique de ports du namespace vers l'hôte ; le port explicite choisit le service requis ici. L'option distincte pasta:--map-gw concerne l'accès à l'hôte par l'adresse de la passerelle, ce qui est une autre disposition.

Avec Compose, inspectez le fournisseur réel et la configuration réseau générée. Un réseau bridge nommé n'est pas automatiquement un namespace pasta simplement parce qu'une commande podman run indépendante a utilisé pasta avec succès. Un moteur Podman distant place aussi « l'hôte » à l'emplacement du moteur.

Articles similaires