Ansible SOCKS-volmag: watter masjien besit localhost?
Spoor die proses op wat 'n Ansible-API-versoek maak voordat jy dit na 'n SSH SOCKS-luisteraar op loopback wys.
'n Taak wat socks5h://127.0.0.1:65432 gebruik, moet in die netwerk-omgewing hardloop waar daardie luisteraar bestaan. 'n Tonnel wat vanaf die beheerder werk, maak dit nie beskikbaar by 'n bestuurde gasheer se loopback-adres—of binne 'n uitvoeringshouer nie.
Vir die mislukte taak, stel vier feite vas:
- Die gasheer of houer wat die netwerkversoek uitvoer.
- Sy effektiewe gebruiker en Python-tolk.
- Die module se HTTP-biblioteek of SDK.
- Die adres waar daardie proses die SOCKS-luisteraar kan bereik.
Die play se inventaris-teiken alleen beantwoord nie die eerste vraag nie. Modules gebruik hul gekonfigureerde verbinding, delegasie kan uitvoering verskuif, en 'n plaaslike verbinding kan werk op die beheerder hou. Opsoekings aan die beheerder se kant gebeur heeltemal buite die afgeleë module.
Vir 'n OpenStack-beeldtaak, ondersoek die geïnstalleerde openstack.cloud-versameling se vereistes en sy OpenStack SDK-omgewing. Dat curl elders slaag, bewys nie daardie SDK se SOCKS-vermoëns of afhanklikhede nie.
As die API-bewerking bedoel is om plaaslik te hardloop, maak daardie uitvoeringskeuse eksplisiet en verskaf die instelling daar. As dit op afstand hardloop, kies 'n volmag wat vanuit daardie konteks bereikbaar is. Ansible se taak environment: beïnvloed die taakproses; dit herkonfigureer nie elke opsoeking of invoegprogram nie, en die SDK moet steeds die skema in daardie Python-omgewing ondersteun.
Hou twee roetes apart: SSH of ProxyJump kry Ansible by 'n gasheer uit, terwyl die module se HTTP-kliënt van sy uitvoeringskonteks na die API kom. 'n Werkende eerste roete konfigureer nie die tweede nie. Om 'n luisteraar wat net op die beheerder bestaan bloot te stel om bereikbaarheid op te los, verander ook wie daaraan toegang het, so dit is 'n ontplooiingskeuse eerder as 'n adresregstelling.