Ansible SOCKS-proxy: kva maskin eig localhost?

Finn prosessen som sender ein Ansible API-førespurnad før du peikar han mot ein SSH SOCKS-lyttar på loopback.

Ei oppgåve som brukar socks5h://127.0.0.1:65432, må køyre i nettverksmiljøet der den lyttaren finst. Ein tunnel som verkar frå kontrolløren, gjer han ikkje tilgjengeleg på loopback-adressa til ein administrert vert — eller inne i ein køyringscontainer.

For oppgåva som feilar, fastset fire fakta:

  1. Verten eller containeren som utfører nettverksførespurnaden.
  2. Den effektive brukaren og Python-tolken hans.
  3. HTTP-biblioteket eller SDK-en til modulen.
  4. Adressa der prosessen kan nå SOCKS-lyttaren.

Berre inventarmålet til stykket svarar ikkje på det første spørsmålet. Modulane brukar den konfigurerte tilkoplinga si, delegering kan flytte køyringa, og ei lokal tilkopling kan halde arbeidet på kontrolløren. Oppslag på kontrollørsida skjer heilt utanfor den eksterne modulen.

For ei OpenStack-bildeoppgåve, gransk krava til den installerte openstack.cloud-samlinga og OpenStack SDK-miljøet hennar. At curl lykkast andre stader, provar ikkje SOCKS-eigenskapane eller avhengnadene til den SDK-en.

Viss API-operasjonen skal køyre lokalt, gjer det køyringsvalet eksplisitt og oppgi innstillinga der. Viss han køyrer eksternt, vel ein proxy som er tilgjengeleg frå den konteksten. environment: til Ansible-oppgåva påverkar oppgåveprosessen; det omkonfigurerer ikkje kvart oppslag eller kvar programtillegg, og SDK-en må framleis støtte skjemaet i det Python-miljøet.

Hald to ruter skilde: SSH eller ProxyJump bringar Ansible til ein vert, medan HTTP-klienten til modulen går frå køyringskonteksten sin til API-et. Ei fungerande første rute konfigurerer ikkje den andre. Å eksponere ein lyttar som berre finst på kontrolløren for å løyse tilgjenge endrar òg kven som kan nå han, så det er eit distribusjonsval og ikkje ein adressekorreksjon.

Relaterte artiklar