ホストの 127.0.0.1:8118 とコンテナの 127.0.0.1:8118 は通常、別々の loopback エンドポイントです。プロキシ変数を rootless コンテナに渡しても、これらの loopback インターフェースは結合されません。

pasta を使う Podman デプロイでは、namespace からホストへの TCP 転送によって、目的のホストポートを 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

アプリケーション既存のイメージとコマンドを使います。この例は、ホスト側のポート 8118 で HTTP プロキシが動作しており、示された転送オプションをサポートする Podman/pasta バージョンがあることを前提としています。

pasta の大文字 -T は、対象 namespace からホスト namespace へ転送します。小文字 -t と Podman の --publish は逆方向を扱います。したがって、コンテナポート 8118 を公開しても、それだけでホストのプロキシがコンテナから利用可能になるわけではありません。

Podman は既定で namespace からホストへの自動ポート転送を無効にします。明示的なポートがここで必要なサービスを選びます。別の pasta:--map-gw オプションはゲートウェイアドレス経由でホストに到達するためのもので、これは別の構成です。

Compose では、実際のプロバイダーと生成されたネットワーク設定を確認してください。名前付きブリッジネットワークは、独立した podman run コマンドが pasta を正常に使ったという理由だけで自動的に pasta namespace になるわけではありません。リモートの Podman エンジンも「ホスト」をエンジンの場所に置きます。

関連記事