Ansible SOCKS tarpinis serveris: kuris kompiuteris valdo localhost?

Nustatykite procesą, kuris siunčia Ansible API užklausą, prieš nukreipdami jį į SSH SOCKS klausytoją loopback sąsajoje.

Užduotis, naudojanti socks5h://127.0.0.1:65432, turi veikti tinklo aplinkoje, kurioje egzistuoja tas klausytojas. Tunelis, veikiantis iš valdiklio, nepadaro jo prieinamo valdomo pagrindinio kompiuterio loopback adresu — arba vykdymo konteinerio viduje.

Nepavykusiai užduočiai nustatykite keturis faktus:

  1. Pagrindinis kompiuteris arba konteineris, vykdantis tinklo užklausą.
  2. Jo efektyvusis naudotojas ir Python interpretatorius.
  3. Modulio HTTP biblioteka arba SDK.
  4. Adresas, kuriuo šis procesas gali pasiekti SOCKS klausytoją.

Vien tik pjesės inventorizacijos tikslas neatsako į pirmąjį klausimą. Moduliai naudoja savo sukonfigūruotą ryšį, delegavimas gali perkelti vykdymą, o vietinis ryšys gali palikti darbą valdiklyje. Paieškos valdiklio pusėje vyksta visiškai už nuotolinio modulio.

OpenStack atvaizdžio užduočiai patikrinkite įdiegto openstack.cloud rinkinio reikalavimus ir jo OpenStack SDK aplinką. curl sėkmė kitur neįrodo to SDK SOCKS galimybių ar priklausomybių.

Jei API operacija turi veikti vietoje, padarykite tą vykdymo pasirinkimą aiškų ir nurodykite nuostatą ten. Jei ji veikia nuotoliniu būdu, pasirinkite tarpinį serverį, pasiekiamą iš tos aplinkos. Ansible užduoties environment: veikia užduoties procesą; jis neperkonfigūruoja kiekvienos paieškos ar papildinio, o SDK vis tiek turi palaikyti schemą toje Python aplinkoje.

Laikykite du maršrutus atskirai: SSH arba ProxyJump nuveda Ansible iki pagrindinio kompiuterio, o modulio HTTP klientas keliauja iš savo vykdymo aplinkos į API. Veikiantis pirmasis maršrutas nesukonfigūruoja antrojo. Tik valdiklyje esančio klausytojo atvėrimas pasiekiamumui spręsti taip pat keičia, kas gali jį pasiekti, todėl tai diegimo sprendimas, o ne adreso korekcija.

Susiję straipsniai