Ansible'i SOCKS-puhverserver: milline masin omab localhosti?
Tuvastage protsess, mis teeb Ansible'i API-päringu, enne kui suunate selle loopbackil asuvale SSH SOCKS-kuulajale.
socks5h://127.0.0.1:65432 kasutav ülesanne peab töötama võrgukeskkonnas, kus see kuulaja eksisteerib. Kontrollerist töötav tunnel ei tee seda kättesaadavaks hallatava hosti loopback-aadressil — ega täitmiskonteineri sees.
Ebaõnnestuva ülesande puhul tuvastage neli asjaolu:
- Võrgupäringu täitev host või konteiner.
- Selle tegelik kasutaja ja Pythoni interpretaator.
- Mooduli HTTP-teek või SDK.
- Aadress, kus see protsess pääseb SOCKS-kuulajani.
Ainuüksi näidendi inventari siht ei vasta esimesele küsimusele. Moodulid kasutavad oma seadistatud ühendust, delegeerimine võib täitmist liigutada ja kohalik ühendus võib töö kontrollerile jätta. Kontrolleripoolsed otsingud toimuvad täiesti väljaspool kaugmoodulit.
OpenStacki kujutise ülesande puhul uurige paigaldatud openstack.cloud kogumi nõudeid ja selle OpenStack SDK keskkonda. curl'i õnnestumine mujal ei tõenda selle SDK SOCKS-võimekust ega sõltuvusi.
Kui API-toiming peaks töötama kohapeal, tehke see täitmisvalik selgeks ja andke seade seal. Kui see töötab kaugelt, valige kontekstist kättesaadav puhverserver. Ansible'i ülesande environment: mõjutab ülesande protsessi; see ei seadista ümber iga otsingut ega pluginat ning SDK peab selles Pythoni keskkonnas skeemi endiselt toetama.
Hoidke kaks marsruuti eraldi: SSH või ProxyJump viib Ansible'i hostini, samal ajal kui mooduli HTTP-klient jõuab oma täitmiskontekstist API-ni. Töötav esimene marsruut ei seadista teist. Ainult kontrolleril oleva kuulaja paljastamine kättesaadavuse lahendamiseks muudab ka seda, kes sellele ligi pääseb, seega on see juurutamisotsus, mitte aadressi parandus.