Proxy SOCKS de Ansible: que máquina posúe localhost?
Localice o proceso que fai unha solicitude á API de Ansible antes de apuntalo a un escoitador SSH SOCKS en loopback.
Unha tarefa que usa socks5h://127.0.0.1:65432 debe executarse na contorna de rede onde existe ese escoitador. Un túnel que funciona desde o controlador non o fai dispoñible en o enderezo loopback dun anfitrión xestionado — nin dentro dun contedor de execución.
Para a tarefa que falla, estableza catro feitos:
- O anfitrión ou contedor que executa a solicitude de rede.
- O seu usuario efectivo e o seu intérprete de Python.
- A biblioteca HTTP ou o SDK do módulo.
- O enderezo no que ese proceso pode alcanzar o escoitador SOCKS.
O destino de inventario da obra por si só non responde á primeira pregunta. Os módulos usan a súa conexión configurada, a delegación pode mover a execución e unha conexión local pode manter o traballo no controlador. As buscas do lado do controlador ocorren completamente fóra do módulo remoto.
Para unha tarefa de imaxe de OpenStack, revise os requisitos da colección openstack.cloud instalada e a súa contorna de SDK de OpenStack. Que curl funcione noutro lugar non demostra as capacidades SOCKS nin as dependencias dese SDK.
Se a operación da API debe executarse localmente, faga explícita esa elección de execución e proporcione alí a configuración. Se se executa de forma remota, elixa un proxy accesible desde esa contorna. O environment: da tarefa de Ansible afecta o proceso da tarefa; non reconfigura cada busca nin cada complemento, e o SDK segue necesitando admitir o esquema nesa contorna de Python.
Manteña dúas rutas separadas: SSH ou ProxyJump leva Ansible ata un anfitrión, mentres que o cliente HTTP do módulo vai desde a súa contorna de execución ata a API. Unha primeira ruta que funciona non configura a segunda. Expór un escoitador que só existe no controlador para resolver a accesibilidade tamén cambia quen pode acceder a el, así que é unha decisión de despregamento e non unha corrección de enderezo.