Ansible SOCKS-proxy: welke machine bezit localhost?
Localiseer het proces dat een Ansible-API-verzoek doet voordat u het naar een SSH SOCKS-listener op loopback wijst.
Een taak die socks5h://127.0.0.1:65432 gebruikt, moet draaien in de netwerkomgeving waar die listener bestaat. Een tunnel die vanaf de controller werkt, maakt hem niet beschikbaar op het loopbackadres van een beheerde host — of binnen een uitvoeringscontainer.
Stel voor de mislukkende taak vier feiten vast:
- De host of container die het netwerkverzoek uitvoert.
- De effectieve gebruiker en Python-interpreter.
- De HTTP-bibliotheek of SDK van de module.
- Het adres waarop dat proces de SOCKS-listener kan bereiken.
Alleen het inventarisdoel van de play beantwoordt de eerste vraag niet. Modules gebruiken hun geconfigureerde verbinding, delegatie kan de uitvoering verplaatsen, en een lokale verbinding kan het werk op de controller houden. Opzoekingen aan de controllerzijde gebeuren volledig buiten de externe module.
Controleer voor een OpenStack-imagetaak de vereisten van de geïnstalleerde openstack.cloud-collectie en de OpenStack SDK-omgeving ervan. Dat curl elders werkt, bewijst de SOCKS-mogelijkheden of afhankelijkheden van die SDK niet.
Als de API-bewerking lokaal moet draaien, maak die uitvoeringskeuze dan expliciet en geef de instelling daar. Draait hij op afstand, kies dan een proxy die vanuit die context bereikbaar is. De environment: van de Ansible-taak beïnvloedt het taakproces; het herconfigureert niet elke opzoeking of plugin, en de SDK moet het schema in die Python-omgeving nog steeds ondersteunen.
Houd twee routes gescheiden: SSH of ProxyJump brengt Ansible naar een host, terwijl de HTTP-client van de module van zijn uitvoeringscontext naar de API gaat. Een werkende eerste route configureert de tweede niet. Een listener die alleen op de controller bestaat blootstellen om bereikbaarheid op te lossen verandert ook wie er toegang toe heeft, dus dat is een implementatiekeuze en geen adrescorrectie.