Ansible SOCKS-proxy: hvilken maskine ejer localhost?
Find den proces, der sender en Ansible API-anmodning, før du peger den på en SSH SOCKS-lytter på loopback.
En opgave, der bruger socks5h://127.0.0.1:65432, skal køre i det netværksmiljø, hvor den lytter findes. En tunnel, der virker fra controlleren, gør den ikke tilgængelig på en administreret hosts loopback-adresse — eller inde i en eksekveringscontainer.
For den fejlende opgave skal du fastslå fire fakta:
- Den host eller container, der udfører netværksanmodningen.
- Dens effektive bruger og Python-fortolker.
- Modullets HTTP-bibliotek eller SDK.
- Den adresse, hvor den proces kan nå SOCKS-lytteren.
Spillets inventarmål alene besvarer ikke det første spørgsmål. Moduler bruger deres konfigurerede forbindelse, delegering kan flytte udførelsen, og en lokal forbindelse kan holde arbejdet på controlleren. Opslag på controller-siden sker helt uden for det eksterne modul.
For en OpenStack-imageopgave skal du undersøge krav og OpenStack SDK-miljø for den installerede openstack.cloud-samling. At curl virker et andet sted, beviser ikke den SDK's SOCKS-muligheder eller afhængigheder.
Hvis API-operationen skal køre lokalt, skal du gøre det valg eksplicit og angive indstillingen der. Hvis den kører eksternt, skal du vælge en proxy, der kan nås fra den kontekst. environment: for Ansible-opgaven påvirker opgaveprocessen; det omkonfigurerer ikke hvert opslag eller plugin, og SDK'en skal stadig understøtte skemaet i det Python-miljø.
Hold to ruter adskilt: SSH eller ProxyJump bringer Ansible til en host, mens modullets HTTP-klient går fra sin eksekveringskontekst til API'en. En fungerende første rute konfigurerer ikke den anden. At eksponere en lytter, der kun findes på controlleren, for at løse tilgængelighed ændrer også, hvem der kan tilgå den, så det er et implementeringsvalg snarere end en adressekorrektion.