Proxy SOCKS d'Ansible: quin ordinador posseeix localhost?
Localitzeu el procés que fa una sol·licitud a l'API d'Ansible abans d'apuntar-lo a un escoltador SSH SOCKS a loopback.
Una tasca que utilitza socks5h://127.0.0.1:65432 ha de s'executar a l'entorn de xarxa on existeix aquest escoltador. Un túnel que funciona des del controlador no el fa disponible a l'adreça de loopback d'un amfitrió gestionat — ni dins d'un contenidor d'execució.
Per a la tasca que falla, establiu quatre fets:
- L'amfitrió o contenidor que executa la sol·licitud de xarxa.
- El seu usuari efectiu i l'intèrpret de Python.
- La biblioteca HTTP o l'SDK del mòdul.
- L'adreça on aquest procés pot arribar a l'escoltador SOCKS.
Només l'objectiu d'inventari de l'obra no respon la primera pregunta. Els mòduls utilitzen la seva connexió configurada, la delegació pot moure l'execució i una connexió local pot mantenir la feina al controlador. Les consultes al costat del controlador passen totalment fora del mòdul remot.
Per a una tasca d'imatge OpenStack, reviseu els requisits de la col·lecció openstack.cloud instal·lada i el seu entorn d'SDK OpenStack. Que curl funcioni en un altre lloc no demostra les capacitats SOCKS ni les dependències d'aquest SDK.
Si l'operació d'API ha de funcionar localment, feu explícita aquesta elecció d'execució i proporcioneu-hi la configuració. Si funciona remotament, trieu un proxy accessible des d'aquell context. environment: de la tasca d'Ansible afecta el procés de la tasca; no reconfigura cada consulta ni cada connector, i l'SDK encara ha de suportar l'esquema en aquest entorn de Python.
Manteniu dues rutes separades: SSH o ProxyJump porta Ansible a un amfitrió, mentre que el client HTTP del mòdul va des del seu context d'execució fins a l'API. Una primera ruta funcional no configura la segona. Exposar un escoltador només del controlador per resoldre l'abastabilitat també canvia qui hi pot accedir, així que és una decisió de desplegament i no una correcció d'adreça.