Ansible SOCKS 프록시: localhost는 어느 머신의 것인가?
Ansible API 요청을 수행하는 프로세스를 찾은 다음 loopback의 SSH SOCKS 리스너로 향하게 하세요.
socks5h://127.0.0.1:65432를 사용하는 작업은 해당 리스너가 존재하는 네트워크 환경에서 실행되어야 합니다. 컨트롤러에서 동작하는 터널이 있어도 관리 대상 호스트의 loopback 주소나 실행 컨테이너 내부에서는 사용할 수 없습니다.
실패하는 작업에 대해 네 가지 사실을 확인하세요.
- 네트워크 요청을 실행하는 호스트 또는 컨테이너.
- 그것의 유효 사용자와 Python 인터프리터.
- 모듈의 HTTP 라이브러리 또는 SDK.
- 그 프로세스가 SOCKS 리스너에 도달할 수 있는 주소.
플레이의 인벤터리 대상만으로는 첫 번째 질문에 답할 수 없습니다. 모듈은 구성된 연결을 사용하고, 위임은 실행 위치를 옮길 수 있으며, 로컬 연결은 작업을 컨트롤러에 남길 수 있습니다. 컨트롤러 측 조회는 원격 모듈 완전히 밖에서 일어납니다.
OpenStack 이미지 작업이라면 설치된 openstack.cloud 컬렉션의 요구 사항과 그 OpenStack SDK 환경을 확인하세요. 다른 곳에서 curl이 성공한다고 해서 그 SDK의 SOCKS 지원이나 의존성이 증명되지는 않습니다.
API 작업을 로컬에서 실행하려는 의도라면 그 실행 선택을 명시하고 설정을 그곳에 두세요. 원격에서 실행된다면 그 컨텍스트에서 도달할 수 있는 프록시를 고르세요. Ansible 작업의 environment:는 작업 프로세스에 영향을 주지만 모든 조회나 플러그인을 다시 구성하지는 않으며, SDK는 해당 Python 환경에서 스킴을 계속 지원해야 합니다.
두 경로를 분리하세요. SSH 또는 ProxyJump는 Ansible을 호스트까지 데려가고, 모듈의 HTTP 클라이언트는 실행 컨텍스트에서 API까지 갑니다. 동작하는 첫 번째 경로가 두 번째를 구성하지는 않습니다. 컨트롤러에만 있는 리스너를 도달성 문제 때문에 노출하면 누가 접근할 수 있는지도 바뀌므로, 이는 주소 수정이 아니라 배포 결정입니다.