O 127.0.0.1:8118 do host e o 127.0.0.1:8118 do contedor adoitan ser puntos finais de loopback separados. Pasar unha variable de proxy a un contedor sen root non une esas interfaces de loopback.

Nun despregamento de Podman que usa pasta, o seu reenvío TCP do namespace ao host pode expoñer o porto de host previsto dentro do 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

Use a imaxe e o comando existentes da aplicación. O exemplo supón un proxy HTTP funcional no lado do host no porto 8118 e unha versión de Podman/pasta que admite a opción de reenvío mostrada.

A -T maiúscula de pasta reenvía desde o namespace de destino cara ao namespace do host. A -t minúscula e --publish de Podman abordan a dirección oposta. Por tanto, publicar o porto 8118 do contedor non fai, por si só, que o proxy do host estea dispoñible para o contedor.

Podman desactiva por defecto o reenvío automático de portos do namespace ao host; o porto explícito escolle o servizo necesario aquí. A opción separada pasta:--map-gw refírese a chegar ao host mediante o enderezo da pasarela, que é outra disposición.

Con Compose, inspeccione o provedor real e a configuración de rede xerada. Unha rede de ponte con nome non é automaticamente un namespace de pasta só porque un comando podman run independente usase pasta correctamente. Un motor Podman remoto tamén sitúa o «host» na localización do motor.

Artigos relacionados