호스트의 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 엔진도 “호스트”를 엔진의 위치에 둡니다.

관련 글