Ansible SOCKS proxy: localhost ເປັນຂອງເຄື່ອງໃດ?

ກຳນົດຂະບວນການທີ່ສົ່ງຄຳຮ້ອງ Ansible API ກ່ອນທີ່ຈະຊີ້ໄປຫາຜູ້ຮັບຟັງ SSH SOCKS ເທິງ loopback.

ໜ້າວຽກທີ່ໃຊ້ socks5h://127.0.0.1:65432 ຕ້ອງແລ່ນໃນສະພາບແວດລ້ອມເຄືອຂ່າຍທີ່ມີຜູ້ຮັບຟັງນັ້ນ. ອຸໂມງທີ່ເຮັດວຽກຈາກຕົວຄວບຄຸມບໍ່ໄດ້ເຮັດໃຫ້ມັນໃຊ້ໄດ້ທີ່ ທີ່ຢູ່ loopback ຂອງເຄື່ອງທີ່ຖືກຈັດການ — ຫຼືພາຍໃນຄອນເທນເນີທີ່ປະຕິບັດ.

ສຳລັບໜ້າວຽກທີ່ລົ້ມເຫລວ, ກຳນົດຂໍ້ເທັດຈິງສີ່ຢ່າງ:

  1. ເຄື່ອງ ຫຼື ຄອນເທນເນີທີ່ປະຕິບັດຄຳຮ້ອງເຄືອຂ່າຍ.
  2. ຜູ້ໃຊ້ທີ່ມີຜົນ ແລະ ຕົວແປ Python ຂອງມັນ.
  3. ຫ້ອງສະໝຸດ HTTP ຫຼື SDK ຂອງໂມດູນ.
  4. ທີ່ຢູ່ທີ່ຂະບວນການນັ້ນສາມາດໄປຮອດຜູ້ຮັບຟັງ SOCKS.

ພຽງແຕ່ເປົ້າໝາຍ inventory ຂອງ play ບໍ່ຕອບຄຳຖາມທຳອິດ. ໂມດູນໃຊ້ການເຊື່ອມຕໍ່ທີ່ຕັ້ງໄວ້, ການມອບໝາຍສາມາດຍ້າຍການປະຕິບັດ, ແລະ ການເຊື່ອມຕໍ່ທ້ອງຖິ່ນສາມາດເກັບວຽກໄວ້ທີ່ຕົວຄວບຄຸມ. ການຄົ້ນຫາທາງຝ່າຍຕົວຄວບຄຸມເກີດຂຶ້ນພາຍນອກໂມດູນທາງໄກທັງໝົດ.

ສຳລັບໜ້າວຽກຮູບພາບ OpenStack, ກວດເບິ່ງຂໍ້ກຳນົດຂອງຊຸດ openstack.cloud ທີ່ຕິດຕັ້ງ ແລະ ສະພາບແວດລ້ອມ OpenStack SDK ຂອງມັນ. ການທີ່ curl ສຳເລັດຢູ່ບ່ອນອື່ນບໍ່ໄດ້ພິສູດຄວາມສາມາດ SOCKS ຫຼື ການຂຶ້ນກັບຂອງ SDK ນັ້ນ.

ຖ້າການດຳເນີນການ API ຖືກອອກແບບໃຫ້ແລ່ນໃນທ້ອງຖິ່ນ, ເຮັດໃຫ້ການເລືອກປະຕິບັດນັ້ນຊັດເຈນ ແລະ ໃຫ້ການຕັ້ງຄ່າຢູ່ທີ່ນັ້ນ. ຖ້າມັນແລ່ນຈາກທາງໄກ, ເລືອກ proxy ທີ່ເຂົ້າເຖິງໄດ້ຈາກບໍລິບົດນັ້ນ. environment: ຂອງໜ້າວຽກ Ansible ສົ່ງຜົນຕໍ່ຂະບວນການຂອງໜ້າວຽກ; ມັນບໍ່ຕັ້ງຄ່າຄືນທຸກການຄົ້ນຫາ ຫຼື ປລັກອິນ, ແລະ SDK ຍັງຕ້ອງຮອງຮັບ scheme ໃນສະພາບແວດລ້ອມ Python ນັ້ນ.

ແຍກສອງເສັ້ນທາງ: SSH ຫຼື ProxyJump ນຳ Ansible ໄປຫາເຄື່ອງ, ຂະນະທີ່ HTTP client ຂອງໂມດູນໄປຈາກບໍລິບົດການປະຕິບັດຂອງມັນໄປຫາ API. ເສັ້ນທາງທຳອິດທີ່ເຮັດວຽກບໍ່ໄດ້ຕັ້ງຄ່າເສັ້ນທາງທີສອງ. ການເປີດເຜີຍຜູ້ຮັບຟັງທີ່ມີພຽງແຕ່ເທິງຕົວຄວບຄຸມເພື່ອແກ້ການເຂົ້າເຖິງຍັງປ່ຽນວ່າໃຜສາມາດເຂົ້າເຖິງໄດ້, ດັ່ງນັ້ນມັນເປັນການເລືອກການຕິດຕັ້ງ ບໍ່ແມ່ນການແກ້ໄຂທີ່ຢູ່.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ