Podman pasta: llegar a un proxy loopback del host desde un contenedor sin root

El 127.0.0.1:8118 del host y el 127.0.0.1:8118 del contenedor suelen ser puntos finales de loopback separados. Pasar una variable de proxy a un contenedor sin root no une esas interfaces de loopback.

En un despliegue de Podman que usa pasta, su reenvío TCP del espacio de nombres al host puede exponer el puerto de host previsto dentro del espacio de nombres:

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 la imagen y el comando existentes de la aplicación. El ejemplo supone un proxy HTTP funcional en el lado del host en el puerto 8118 y una versión de Podman/pasta que admita la opción de reenvío mostrada.

La -T mayúscula de pasta reenvía desde el espacio de nombres de destino hacia el espacio de nombres del host. La -t minúscula y --publish de Podman abordan la dirección opuesta. Por lo tanto, publicar el puerto 8118 del contenedor no hace, por sí solo, que el proxy del host esté disponible para el contenedor.

Podman desactiva de forma predeterminada el reenvío automático de puertos del espacio de nombres al host; el puerto explícito elige el servicio necesario aquí. La opción separada pasta:--map-gw se refiere a llegar al host mediante la dirección de la puerta de enlace, que es otra disposición.

Con Compose, inspeccione el proveedor real y la configuración de red generada. Una red de puente con nombre no es automáticamente un espacio de nombres de pasta solo porque un comando podman run independiente haya usado pasta correctamente. Un motor Podman remoto también sitúa el «host» en la ubicación del motor.