SOCKS-проксі в Ansible: якій машині належить localhost?

Визначте процес, що надсилає запит до API Ansible, перш ніж спрямовувати його на SSH SOCKS-слухач на loopback.

Завдання, що використовує socks5h://127.0.0.1:65432, має виконуватися в тому мережевому середовищі, де існує цей слухач. Тунель, що працює з контролера, не робить його доступним на адресі loopback керованого хоста — або всередині контейнера виконання.

Для збійного завдання встановіть чотири факти:

  1. Хост або контейнер, що виконує мережевий запит.
  2. Його чинний користувач і інтерпретатор Python.
  3. HTTP-бібліотека або SDK модуля.
  4. Адреса, за якою цей процес може досягти SOCKS-слухача.

Лише цільовий хост з інвентаря п'єси не відповідає на перше питання. Модулі використовують налаштоване з'єднання, делегування може перемістити виконання, а локальне з'єднання може залишити роботу на контролері. Пошуки на боці контролера відбуваються повністю поза віддаленим модулем.

Для завдання з образом OpenStack перевірте вимоги встановленої колекції openstack.cloud та її середовище OpenStack SDK. Успішний curl в іншому місці не доводить можливості SOCKS чи залежності цього SDK.

Якщо операція API має виконуватися локально, зробіть цей вибір виконання явним і задайте налаштування там. Якщо вона виконується віддалено, виберіть проксі, доступний із цього контексту. environment: завдання Ansible впливає на процес завдання; він не переналаштовує кожен пошук чи плагін, і SDK усе ще має підтримувати схему в цьому середовищі Python.

Тримайте два маршрути окремо: SSH або ProxyJump доставляє Ansible на хост, а HTTP-клієнт модуля йде зі свого контексту виконання до API. Робочий перший маршрут не налаштовує другий. Відкриття слухача, що існує лише на контролері, для вирішення доступності також змінює, хто може до нього підключитися, тому це рішення про розгортання, а не виправлення адреси.

Схожі статті