127.0.0.1:8118 des Hosts und 127.0.0.1:8118 des Containers sind normalerweise getrennte Loopback-Endpunkte. Eine Proxy-Variable in einen rootless Container zu übergeben, verbindet diese Loopback-Schnittstellen nicht.

Bei einem Podman-Deployment mit pasta kann dessen TCP-Weiterleitung vom Namespace zum Host den gewünschten Host-Port innerhalb des Namespace freigeben:

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

Verwenden Sie das vorhandene Image und den vorhandenen Befehl der Anwendung. Das Beispiel setzt einen funktionierenden HTTP-Proxy auf der Hostseite an Port 8118 und eine Podman/pasta-Version voraus, die die gezeigte Weiterleitungsoption unterstützt.

Das große -T von pasta leitet vom Ziel-Namespace zum Host-Namespace weiter. Das kleine -t und Podmans --publish adressieren die entgegengesetzte Richtung. Das Veröffentlichen von Container-Port 8118 macht den Host-Proxy daher nicht von selbst für den Container verfügbar.

Podman deaktiviert standardmäßig die automatische Portweiterleitung vom Namespace zum Host; der explizite Port wählt den hier benötigten Dienst. Die separate Option pasta:--map-gw betrifft den Zugriff auf den Host über die Gateway-Adresse, was eine andere Anordnung ist.

Prüfen Sie bei Compose den tatsächlichen Anbieter und die erzeugte Netzwerkkonfiguration. Ein benanntes Bridge-Netzwerk ist nicht automatisch ein pasta-Namespace, nur weil ein unabhängiger podman run-Befehl pasta erfolgreich verwendet hat. Eine entfernte Podman-Engine platziert „Host“ ebenfalls am Standort der Engine.

Ähnliche Artikel