Proxy SOCKS di Ansible: quale macchina possiede localhost?
Individuate il processo che effettua una richiesta API Ansible prima di indirizzarlo verso un listener SSH SOCKS sul loopback.
Un task che usa socks5h://127.0.0.1:65432 deve essere eseguito nell'ambiente di rete in cui esiste quel listener. Un tunnel funzionante dal controller non lo rende disponibile su l'indirizzo di loopback di un host gestito — né dentro un container di esecuzione.
Per il task che fallisce, stabilite quattro fatti:
- L'host o il container che esegue la richiesta di rete.
- Il suo utente effettivo e l'interprete Python.
- La libreria HTTP o l'SDK del modulo.
- L'indirizzo su cui quel processo può raggiungere il listener SOCKS.
Il solo target dell'inventario del play non risponde alla prima domanda. I moduli usano la loro connessione configurata, la delega può spostare l'esecuzione e una connessione locale può mantenere il lavoro sul controller. Le ricerche lato controller avvengono del tutto fuori dal modulo remoto.
Per un task immagine OpenStack, esaminate i requisiti della raccolta openstack.cloud installata e il suo ambiente SDK OpenStack. Il successo di curl altrove non dimostra le capacità SOCKS né le dipendenze di quell'SDK.
Se l'operazione API deve essere eseguita localmente, rendete esplicita questa scelta di esecuzione e fornite lì l'impostazione. Se viene eseguita da remoto, scegliete un proxy raggiungibile da quel contesto. Il environment: del task Ansible influisce sul processo del task; non riconfigura ogni ricerca o plugin, e l'SDK deve comunque supportare lo schema in quell'ambiente Python.
Tenete separate due rotte: SSH o ProxyJump porta Ansible fino a un host, mentre il client HTTP del modulo va dal suo contesto di esecuzione all'API. Una prima rotta funzionante non configura la seconda. Esporre un listener presente solo sul controller per risolvere la raggiungibilità cambia anche chi può accedervi, quindi è una scelta di distribuzione e non una correzione di indirizzo.