Ansible SOCKS proxy-a: zein makinak du localhost?
Kokatu Ansible API eskaera egiten duen prozesua, loopbackeko SSH SOCKS entzule batera bideratu aurretik.
socks5h://127.0.0.1:65432 erabiltzen duen zereginak entzule hori dagoen sare-ingurunean exekutatu behar du. Kontroladoretik funtzionatzen duen tunel batek ez du eskuragarri egiten kudeatutako ostalari baten loopback helbidean — ezta exekuzio-edukiontzi baten barruan ere.
Huts egiten duen zereginerako, ezarri lau gertaera:
- Sare-eskaera exekutatzen duen ostalaria edo edukiontzia.
- Haren erabiltzaile efektiboa eta Python interpretea.
- Moduluaren HTTP liburutegia edo SDK-a.
- Prozesu horrek SOCKS entzulea iristeko duen helbidea.
Antzezlanaren inbentario-helburuak bakarrik ez dio lehen galderari erantzuten. Moduluek beren konexio konfiguratua erabiltzen dute, delegazioak exekuzioa mugi dezake eta konexio lokal batek lana kontroladorean mantendu dezake. Kontroladorearen aldeko bilaketak urruneko modulutik erabat kanpo gertatzen dira.
OpenStack irudi-zeregin baterako, aztertu instalatutako openstack.cloud bildumaren baldintzak eta haren OpenStack SDK ingurunea. curl beste leku batean arrakastatsua izateak ez ditu SDK horren SOCKS gaitasunak edo mendekotasunak frogatzen.
API eragiketa lokalki exekutatzeko asmoa badago, egin exekuzio-hautu hori esplizitu eta eman ezarpena han. Urrutitik exekutatzen bada, aukeratu testuinguru horretatik irisgarria den proxy bat. Ansible zereginaren environment:-k zereginaren prozesuan eragiten du; ez ditu bilaketa eta plugin guztiak birkonfiguratzen, eta SDK-ak Python ingurune horretan eskema onartzen jarraitu behar du.
Mantendu bi ibilbide bereizita: SSH edo ProxyJump-ek Ansible ostalari batera eramaten du, eta moduluaren HTTP bezeroak bere exekuzio-testuingurutik APIra egiten du. Funtzionatzen duen lehen ibilbideak ez du bigarrena konfiguratzen. Kontroladorean soilik dagoen entzule bat irisgarritasuna konpontzeko agertzeak nor sar daitekeen ere aldatzen du, beraz zabalkuntza-erabakia da, ez helbide-zuzenketa.