Podman pasta: chegar a un proxy loopback do host desde un contedor sen root
Use o reenvío TCP de pasta do namespace ao host para un proxy loopback existente e mantéñao separado da publicación dun porto de contedor.
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-commandUse 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.