SOCKS-проксі Ansible: якая машына валодае localhost?
Вызначце працэс, які робіць запыт да API Ansible, перш чым накіроўваць яго на SSH SOCKS-слухач на loopback.
Задача, якая выкарыстоўвае socks5h://127.0.0.1:65432, павінна працаваць у сеткавым асяроддзі, дзе існуе гэты слухач. Тунель, які працуе з кантролера, не робіць яго даступным на loopback-адрасе кіраванага хоста — або ўнутры кантэйнера выканання.
Для задачы, якая не ўдалася, устанавіце чатыры факты:
- Хост або кантэйнер, які выконвае сеткавы запыт.
- Яго эфектыўны карыстальнік і інтэрпрэтатар Python.
- HTTP-бібліятэка або SDK модуля.
- Адрас, па якім гэты працэс можа дасягнуць SOCKS-слухача.
Адзін толькі цэльвы хост з inventory не адказвае на першае пытанне. Модулі выкарыстоўваюць сваё настроенае злучэнне, дэлегаванне можа пераносіць выкананне, а лакальнае злучэнне можа пакінуць працу на кантролеры. Пошукі на баку кантролера адбываюцца цалкам па-за аддаленым модулем.
Для задачы з вобразам OpenStack праверце патрабаванні ўсталяванай калекцыі openstack.cloud і яе асяроддзе OpenStack SDK. Паспяховы curl у іншым месцы не даказвае наяўнасць у гэтага SDK падтрымкі SOCKS або залежнасцей.
Калі аперацыя API павінна выконвацца лакальна, зрабіце гэты выбар выканання яўным і задайце наладу там. Калі яна выконваецца аддалена, выберыце проксі, дасяжны з гэтага кантэксту. environment: задачы Ansible ўплывае на працэс задачы; ён не перанастройвае кожны пошук або плагін, і SDK па-ранейшаму павінен падтрымліваць схему ў гэтым асяроддзі Python.
Трымайце два маршруты асобна: SSH або ProxyJump дастаўляе Ansible на хост, а HTTP-кліент модуля дастаўляе з яго кантэксту выканання да API. Працоўны першы маршрут не настройвае другі. Адкрыццё слухача, які ёсць толькі на кантролеры, для вырашэння дасяжнасці таксама змяняе, хто можа да яго звяртацца, таму гэта рашэнне аб разгортванні, а не выпраўленне адраса.