Proxy SOCKS do Ansible: qual máquina é dona do localhost?
Localize o processo que faz uma solicitação à API do Ansible antes de apontá-lo para um ouvinte SSH SOCKS no loopback.
Uma tarefa que usa socks5h://127.0.0.1:65432 deve ser executada no ambiente de rede onde esse ouvinte existe. Um túnel que funciona a partir do controlador não o torna disponível no endereço de loopback de um host gerenciado — nem dentro de um contêiner de execução.
Para a tarefa que falha, estabeleça quatro fatos:
- O host ou contêiner que executa a solicitação de rede.
- Seu usuário efetivo e interpretador Python.
- A biblioteca HTTP ou o SDK do módulo.
- O endereço em que esse processo pode alcançar o ouvinte SOCKS.
Apenas o alvo do inventário da peça não responde à primeira pergunta. Os módulos usam a conexão configurada, a delegação pode mover a execução e uma conexão local pode manter o trabalho no controlador. As consultas do lado do controlador ocorrem totalmente fora do módulo remoto.
Para uma tarefa de imagem OpenStack, inspecione os requisitos da coleção openstack.cloud instalada e seu ambiente de SDK OpenStack. O sucesso do curl em outro lugar não comprova as capacidades SOCKS nem as dependências desse SDK.
Se a operação de API deve ser executada localmente, torne essa escolha de execução explícita e forneça a configuração ali. Se ela executa remotamente, escolha um proxy alcançável a partir desse contexto. O environment: da tarefa do Ansible afeta o processo da tarefa; ele não reconfigura cada consulta ou plugin, e o SDK ainda precisa suportar o esquema nesse ambiente Python.
Mantenha duas rotas separadas: SSH ou ProxyJump leva o Ansible até um host, enquanto o cliente HTTP do módulo vai do seu contexto de execução até a API. Uma primeira rota funcional não configura a segunda. Expor um ouvinte que só existe no controlador para resolver a acessibilidade também muda quem pode acessá-lo, então é uma decisão de implantação e não uma correção de endereço.