Ansible SOCKS-proxy: vilken maskin äger localhost?
Hitta processen som skickar en Ansible API-förfrågan innan du pekar den mot en SSH SOCKS-lyssnare på loopback.
En uppgift som använder socks5h://127.0.0.1:65432 måste köras i nätverksmiljön där lyssnaren finns. En tunnel som fungerar från kontrollern gör den inte tillgänglig på en hanterad hosts loopback-adress — eller inuti en körningscontainer.
För den misslyckade uppgiften, fastställ fyra fakta:
- Värden eller containern som utför nätverksförfrågan.
- Dess effektiva användare och Python-tolk.
- Modulens HTTP-bibliotek eller SDK.
- Adressen där processen kan nå SOCKS-lyssnaren.
Enbart spellistans inventariemål besvarar inte den första frågan. Moduler använder sin konfigurerade anslutning, delegering kan flytta körningen och en lokal anslutning kan hålla arbetet på kontrollern. Uppslagningar på kontrollsidan sker helt utanför den fjärrstyrda modulen.
För en OpenStack-avbildningsuppgift, granska kraven för den installerade openstack.cloud-samlingen och dess OpenStack SDK-miljö. Att curl lyckas någon annanstans bevisar inte den SDK:ns SOCKS-förmåga eller beroenden.
Om API-åtgärden ska köras lokalt, gör det valet explicit och ange inställningen där. Om den körs på distans, välj en proxy som nås från den kontexten. environment: för Ansible-uppgiften påverkar uppgiftsprocessen; det konfigurerar inte om varje uppslagning eller plugin, och SDK:n måste fortfarande stödja schemat i den Python-miljön.
Håll två vägar åtskilda: SSH eller ProxyJump tar Ansible till en host, medan modulens HTTP-klient går från sin körningskontext till API:et. En fungerande första väg konfigurerar inte den andra. Att exponera en lyssnare som bara finns på kontrollern för att lösa nåbarhet ändrar också vem som kan nå den, så det är ett driftsättningsval och inte en adresskorrigering.