Proxy SOCKS Ansible: care mașină deține localhost?

Identificați procesul care face o cerere API Ansible înainte de a-l îndrepta către un ascultător SSH SOCKS pe loopback.

O sarcină care folosește socks5h://127.0.0.1:65432 trebuie să ruleze în mediul de rețea în care există acel ascultător. Un tunel care funcționează de pe controler nu îl face disponibil la adresa loopback a unui gazdă administrată — sau în interiorul unui container de execuție.

Pentru sarcina care eșuează, stabiliți patru fapte:

  1. Gazda sau containerul care execută cererea de rețea.
  2. Utilizatorul său efectiv și interpretorul Python.
  3. Biblioteca HTTP sau SDK-ul modulului.
  4. Adresa la care acel proces poate ajunge la ascultătorul SOCKS.

Doar ținta de inventar a piesei nu răspunde la prima întrebare. Modulele își folosesc conexiunea configurată, delegarea poate muta execuția, iar o conexiune locală poate păstra lucrul pe controler. Căutările din partea controlerului au loc complet în afara modulului la distanță.

Pentru o sarcină de imagine OpenStack, inspectați cerințele colecției openstack.cloud instalate și mediul său OpenStack SDK. Succesul curl în altă parte nu dovedește capabilitățile SOCKS sau dependențele acelui SDK.

Dacă operația API trebuie să ruleze local, faceți această alegere de execuție explicită și furnizați setarea acolo. Dacă rulează la distanță, alegeți un proxy accesibil din acel context. environment: sarcinii Ansible afectează procesul sarcinii; nu reconfigurează fiecare căutare sau plugin, iar SDK-ul trebuie în continuare să accepte schema în acel mediu Python.

Țineți două rute separate: SSH sau ProxyJump duce Ansible la o gazdă, în timp ce clientul HTTP al modulului merge din contextul său de execuție la API. O primă rută funcțională nu o configurează pe a doua. Expunerea unui ascultător care există doar pe controler pentru a rezolva accesibilitatea schimbă și cine poate ajunge la el, deci este o decizie de implementare, nu o corecție de adresă.

Articole similare