Proxy SOCKS i Ansible: cila makinë zotëron localhost?
Gjeni procesin që bën një kërkesë API Ansible përpara se ta drejtoni te një dëgjues SSH SOCKS në loopback.
Një detyrë që përdor socks5h://127.0.0.1:65432 duhet të ekzekutohet në mjedisin e rrjetit ku ekziston ai dëgjues. Një tunel që funksionon nga kontrolluesi nuk e bën atë të disponueshëm në adresën loopback të një hosti të menaxhuar — ose brenda një kontejneri ekzekutimi.
Për detyrën që dështon, vërtetoni katër fakte:
- Hosti ose kontejneri që ekzekuton kërkesën e rrjetit.
- Përdoruesi i tij efektiv dhe interpretuesi Python.
- Biblioteka HTTP ose SDK-ja e modulit.
- Adresa në të cilën ai proces mund të arrijë dëgjuesin SOCKS.
Vetëm objektivi i inventarit të dramës nuk i përgjigjet pyetjes së parë. Modulet përdorin lidhjen e tyre të konfiguruar, delegimi mund ta zhvendosë ekzekutimin dhe një lidhje lokale mund ta mbajë punën në kontrollues. Kërkimet nga ana e kontrolluesit ndodhin plotësisht jashtë modulit në distancë.
Për një detyrë imazhi OpenStack, shqyrtoni kërkesat e koleksionit openstack.cloud të instaluar dhe mjedisin e tij OpenStack SDK. Suksesi i curl diku tjetër nuk dëshmon aftësitë SOCKS ose varësitë e atij SDK.
Nëse operacioni API synohet të ekzekutohet lokalisht, bëjeni këtë zgjedhje ekzekutimi eksplicite dhe jepni cilësimin atje. Nëse ekzekutohet nga distanca, zgjidhni një proxy të arritshëm nga ai kontekst. environment: i detyrës Ansible ndikon në procesin e detyrës; nuk rikonfiguron çdo kërkim apo shtojcë, dhe SDK-ja ende duhet të mbështesë skemën në atë mjedis Python.
Mbani dy rrugë të ndara: SSH ose ProxyJump e çon Ansible te një host, ndërsa klienti HTTP i modulit shkon nga konteksti i tij i ekzekutimit te API. Një rrugë e parë që funksionon nuk e konfiguron të dytën. Ekspozimi i një dëgjuesi që ekziston vetëm në kontrollues për të zgjidhur arritshmërinë ndryshon gjithashtu se kush mund t'i qaset, pra është një vendim vendosjeje dhe jo një korrigjim adrese.