Ansible SOCKS-proxy: hvilken maskin eier localhost?
Finn prosessen som sender en Ansible API-forespørsel før du peker den mot en SSH SOCKS-lytter på loopback.
En oppgave som bruker socks5h://127.0.0.1:65432, må kjøre i nettverksmiljøet der den lytteren finnes. En tunnel som virker fra kontrolleren, gjør den ikke tilgjengelig på loopback-adressen til en administrert vert — eller inne i en kjøringsbeholder.
For oppgaven som feiler, fastslå fire fakta:
- Verten eller beholderen som utfører nettverksforespørselen.
- Dens effektive bruker og Python-tolk.
- Modulens HTTP-bibliotek eller SDK.
- Adressen der den prosessen kan nå SOCKS-lytteren.
Bare inventarmålet til stykket besvarer ikke det første spørsmålet. Moduler bruker den konfigurerte tilkoblingen sin, delegering kan flytte kjøringen, og en lokal tilkobling kan holde arbeidet på kontrolleren. Oppslag på kontrollersiden skjer helt utenfor den eksterne modulen.
For en OpenStack-bildeoppgave, undersøk kravene til den installerte openstack.cloud-samlingen og dens OpenStack SDK-miljø. At curl lykkes et annet sted, beviser ikke den SDK-ens SOCKS-egenskaper eller avhengigheter.
Hvis API-operasjonen skal kjøre lokalt, gjør det kjøringsvalget eksplisitt og oppgi innstillingen der. Hvis den kjører eksternt, velg en proxy som er tilgjengelig fra den konteksten. environment: for Ansible-oppgaven påvirker oppgaveprosessen; det omkonfigurerer ikke hvert oppslag eller programtillegg, og SDK-en må fortsatt støtte skjemaet i det Python-miljøet.
Hold to ruter atskilt: SSH eller ProxyJump bringer Ansible til en vert, mens modulens HTTP-klient går fra kjøringskonteksten sin til API-et. En fungerende første rute konfigurerer ikke den andre. Å eksponere en lytter som bare finnes på kontrolleren for å løse tilgjengelighet endrer også hvem som kan nå den, så det er et distribusjonsvalg og ikke en adressekorrigering.