El 127.0.0.1:8118 de l'amfitrió i el 127.0.0.1:8118 del contenidor normalment són punts finals de loopback separats. Passar una variable de proxy a un contenidor sense root no uneix aquestes interfícies de loopback.

En un desplegament de Podman que utilitza pasta, el seu reenviament TCP de l'espai de noms a l'amfitrió pot exposar el port d'amfitrió previst dins de l'espai de noms:

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

Useu la imatge i l'ordre existents de l'aplicació. L'exemple assumeix un proxy HTTP funcional al costat de l'amfitrió al port 8118 i una versió de Podman/pasta que admet l'opció de reenviament mostrada.

La -T majúscula de pasta reenvia de l'espai de noms de destinació cap a l'espai de noms de l'amfitrió. La -t minúscula i --publish de Podman adrecen la direcció oposada. Per tant, publicar el port 8118 del contenidor no fa, per si sol, que el proxy de l'amfitrió estigui disponible per al contenidor.

Podman desactiva per defecte el reenviament automàtic de ports de l'espai de noms a l'amfitrió; el port explícit tria el servei necessari aquí. L'opció separada pasta:--map-gw tracta d'arribar a l'amfitrió mitjançant l'adreça de la passarel·la, que és una altra disposició.

Amb Compose, inspeccioneu el proveïdor real i la configuració de xarxa generada. Una xarxa de pont amb nom no és automàticament un espai de noms de pasta només perquè una ordre podman run independent hagi utilitzat pasta correctament. Un motor Podman remot també situa l'«amfitrió» a la ubicació del motor.

Articles relacionats