ການນໍາໃຊ້ plugins ສິນຄ້າຄົງຄັງຈາກ Ansible Content Collections ໃນ Ansible Tower

ສະພາບແວດລ້ອມ IT ໄດ້ກາຍເປັນຄວາມສັບສົນຫຼາຍຂຶ້ນ. ໃນເງື່ອນໄຂເຫຼົ່ານີ້, ມັນເປັນສິ່ງສໍາຄັນສໍາລັບລະບົບອັດຕະໂນມັດ IT ທີ່ຈະມີຂໍ້ມູນທີ່ທັນສະໄຫມກ່ຽວກັບໂຫນດທີ່ມີຢູ່ໃນເຄືອຂ່າຍແລະຂຶ້ນກັບການປຸງແຕ່ງ. ໃນ Red Hat Ansible Automation Platform, ບັນຫານີ້ຖືກແກ້ໄຂໂດຍຜ່ານອັນທີ່ເອີ້ນວ່າສິນຄ້າຄົງຄັງ (ສິນຄ້າຄົງຄັງ) – ບັນຊີລາຍຊື່ຂອງ nodes ການຄຸ້ມຄອງ.

ໃນຮູບແບບທີ່ງ່າຍທີ່ສຸດຂອງມັນ, ສິນຄ້າຄົງຄັງແມ່ນໄຟລ໌ຄົງທີ່. ນີ້ແມ່ນເຫມາະສົມທີ່ສຸດເມື່ອທ່ານເລີ່ມເຮັດວຽກກັບ Ansible, ແຕ່ເມື່ອອັດຕະໂນມັດເພີ່ມຂຶ້ນ, ມັນບໍ່ພຽງພໍ.

ແລະນັ້ນແມ່ນເຫດຜົນ:

1. ທ່ານປັບປຸງແລະຮັກສາບັນຊີລາຍຊື່ຄົບຖ້ວນຂອງ nodes ທີ່ຖືກຕິດຕາມແນວໃດໃນເວລາທີ່ມີການປ່ຽນແປງຢ່າງຕໍ່ເນື່ອງ, ເມື່ອມີວຽກຫນັກ - ແລະຕໍ່ມາ nodes ເຂົາເຈົ້າດໍາເນີນການ - ມາແລະໄປ?
2. ວິທີການຈັດປະເພດອົງປະກອບຂອງໂຄງສ້າງພື້ນຖານດ້ານໄອທີເພື່ອເລືອກ nodes ໂດຍສະເພາະສໍາລັບການນໍາໃຊ້ອັດຕະໂນມັດໂດຍສະເພາະ?

ສິນຄ້າຄົງຄັງແບບໄດນາມິກໃຫ້ຄໍາຕອບສໍາລັບທັງສອງຄໍາຖາມເຫຼົ່ານີ້ (ສິນຄ້າຄົງຄັງແບບເຄື່ອນໄຫວ) – script ຫຼື plugin ທີ່ຊອກຫາ nodes ອັດຕະໂນມັດ, ໂດຍອ້າງອີງໃສ່ແຫຼ່ງຂອງຄວາມຈິງ. ນອກຈາກນັ້ນ, ສິນຄ້າຄົງຄັງແບບເຄື່ອນໄຫວຈະຈັດປະເພດອັດຕະໂນມັດເປັນກຸ່ມເພື່ອໃຫ້ທ່ານສາມາດເລືອກລະບົບເປົ້າຫມາຍໄດ້ຢ່າງຖືກຕ້ອງສໍາລັບການປະຕິບັດອັດຕະໂນມັດ Ansible ສະເພາະ.

ປລັກອິນສິນຄ້າຄົງຄັງ ໃຫ້ຜູ້ໃຊ້ Ansible ສາມາດເຂົ້າເຖິງແພລະຕະຟອມພາຍນອກເພື່ອຄົ້ນຫາໂຫມດເປົ້າຫມາຍແບບເຄື່ອນໄຫວແລະນໍາໃຊ້ແພລະຕະຟອມເຫຼົ່ານີ້ເປັນແຫຼ່ງຄວາມຈິງໃນເວລາສ້າງສາງ. ບັນຊີລາຍຊື່ມາດຕະຖານຂອງແຫຼ່ງໃນ Ansible ປະກອບມີແພລະຕະຟອມຟັງ AWS EC2, Google GCP ແລະ Microsoft Azure, ແລະຍັງມີ plugins ສິນຄ້າຄົງຄັງອື່ນໆຈໍານວນຫຼາຍສໍາລັບ Ansible.

Ansible Tower ມາພ້ອມກັບຈໍານວນຂອງ plugins ສິນຄ້າຄົງຄັງ, ເຊິ່ງເຮັດວຽກອອກຈາກກ່ອງແລະ, ນອກເຫນືອຈາກເວທີຟັງທີ່ລະບຸໄວ້ຂ້າງເທິງ, ສະຫນອງການເຊື່ອມໂຍງກັບ VMware vCenter, Red Hat OpenStack Platform ແລະ Red Hat Satellite. ສໍາລັບ plugins ເຫຼົ່ານີ້, ທ່ານພຽງແຕ່ຕ້ອງການໃຫ້ຂໍ້ມູນປະຈໍາຕົວເພື່ອເຊື່ອມຕໍ່ກັບແພລະຕະຟອມເປົ້າຫມາຍ, ຫຼັງຈາກນັ້ນພວກເຂົາສາມາດຖືກນໍາໃຊ້ເປັນແຫລ່ງຂໍ້ມູນສິນຄ້າຄົງຄັງໃນ Ansible Tower.

ນອກເຫນືອໄປຈາກ plugins ມາດຕະຖານລວມກັບ Ansible Tower, ຍັງມີ plugins ສິນຄ້າຄົງຄັງອື່ນໆທີ່ສະຫນັບສະຫນູນໂດຍຊຸມຊົນ Ansible. ດ້ວຍການຫັນໄປສູ່ ຄໍເລັກຊັນເນື້ອຫາ Red Hat Ansible ປັ໊ກອິນເຫຼົ່ານີ້ເລີ່ມລວມຢູ່ໃນຄໍເລັກຊັນທີ່ສອດຄ້ອງກັນ.

ໃນບົດຂຽນນີ້, ພວກເຮົາຈະເອົາຕົວຢ່າງຂອງການເຮັດວຽກກັບ plugin ສິນຄ້າຄົງຄັງສໍາລັບ ServiceNow, ແພລະຕະຟອມການຄຸ້ມຄອງການບໍລິການ IT ທີ່ນິຍົມທີ່ລູກຄ້າມັກຈະເກັບຂໍ້ມູນກ່ຽວກັບອຸປະກອນທັງຫມົດຂອງພວກເຂົາຢູ່ໃນ CMDB. ນອກຈາກນັ້ນ, CMDB ສາມາດບັນຈຸບໍລິບົດທີ່ເປັນປະໂຫຍດສໍາລັບການອັດຕະໂນມັດ, ເຊັ່ນຂໍ້ມູນກ່ຽວກັບເຈົ້າຂອງເຄື່ອງແມ່ຂ່າຍ, ລະດັບການບໍລິການ (ການຜະລິດ / ບໍ່ແມ່ນການຜະລິດ), ການປັບປຸງທີ່ຕິດຕັ້ງ, ແລະປ່ອງຢ້ຽມບໍາລຸງຮັກສາ. ປລັກອິນສິນຄ້າຄົງຄັງ Ansible ສາມາດເຮັດວຽກກັບ ServiceNow CMDB ແລະເປັນສ່ວນຫນຶ່ງຂອງການເກັບກໍາ ບໍລິການ ກ່ຽວກັບປະຕູໄດ້ galaxy.ansible.com.

Git repository

ເພື່ອໃຊ້ plugin ສິນຄ້າຄົງຄັງຈາກຄໍເລັກຊັນໃນ Ansible Tower, ມັນຕ້ອງຖືກຕັ້ງເປັນແຫຼ່ງໂຄງການ. ໃນ Ansible Tower, ໂຄງການແມ່ນການປະສົມປະສານກັບບາງປະເພດຂອງລະບົບການຄວບຄຸມເວີຊັນ, ຄືກັບ git repository, ເຊິ່ງສາມາດໃຊ້ເພື່ອ synchronize ບໍ່ພຽງແຕ່ເຄື່ອງຫຼີ້ນແບບອັດຕະໂນມັດ, ແຕ່ຍັງຕົວແປແລະລາຍການສິນຄ້າຄົງຄັງ.

ຕົວຈິງແລ້ວ repository ຂອງພວກເຮົາແມ່ນງ່າຍດາຍຫຼາຍ:

├── collections
│   └── requirements.yml
└── servicenow.yml

ໄຟລ໌ servicenow.yml ປະກອບມີລາຍລະອຽດສໍາລັບ plugin inventory. ໃນກໍລະນີຂອງພວກເຮົາ, ພວກເຮົາພຽງແຕ່ລະບຸຕາຕະລາງໃນ ServiceNow CMDB ທີ່ພວກເຮົາຕ້ອງການໃຊ້. ພວກເຮົາຍັງກໍານົດຊ່ອງຂໍ້ມູນທີ່ຈະເພີ່ມເປັນຕົວແປ node, ບວກກັບຂໍ້ມູນທີ່ແນ່ນອນກ່ຽວກັບກຸ່ມທີ່ພວກເຮົາຕ້ອງການສ້າງ.

$ cat servicenow.yml
plugin: servicenow.servicenow.now
table: cmdb_ci_linux_server
fields: [ip_address,fqdn,host_name,sys_class_name,name,os]
keyed_groups:
  - key: sn_sys_class_name | lower
	prefix: ''
	separator: ''
  - key: sn_os | lower
	prefix: ''
	separator: ''

ກະ​ລຸ​ນາ​ສັງ​ເກດ​ວ່າ​ນີ້​ບໍ່​ໄດ້​ລະ​ບຸ​ຕົວ​ຢ່າງ ServiceNow ທີ່​ພວກ​ເຮົາ​ຈະ​ເຊື່ອມ​ຕໍ່​ໃນ​ວິ​ທີ​ການ​ໃດ​ຫນຶ່ງ​, ແລະ​ບໍ່​ໄດ້​ລະ​ບຸ​ຂໍ້​ມູນ​ສໍາ​ລັບ​ການ​ເຊື່ອມ​ຕໍ່​. ພວກເຮົາຈະປັບຄ່າທັງໝົດໃນພາຍຫຼັງໃນ Ansible Tower.

ໄຟລ໌ການເກັບກໍາ/requirements.yml ທີ່ຈໍາເປັນເພື່ອໃຫ້ Ansible Tower ສາມາດດາວໂຫລດການເກັບກໍາທີ່ຕ້ອງການແລະດັ່ງນັ້ນຈຶ່ງໄດ້ຮັບ plugin ສິນຄ້າຄົງຄັງທີ່ຕ້ອງການ. ຖ້າບໍ່ດັ່ງນັ້ນ, ພວກເຮົາຈະຕ້ອງຕິດຕັ້ງ ແລະຮັກສາຄໍເລັກຊັນນີ້ດ້ວຍຕົນເອງໃນທຸກ nodes Ansible Tower ຂອງພວກເຮົາ.

$ cat collections/requirements.yml
---
collections:

- name: servicenow.servicenow

ເມື່ອພວກເຮົາໄດ້ຍູ້ການຕັ້ງຄ່ານີ້ໄປສູ່ການຄວບຄຸມເວີຊັນ, ພວກເຮົາສາມາດສ້າງໂຄງການໃນ Ansible Tower ທີ່ອ້າງອີງເຖິງບ່ອນເກັບມ້ຽນທີ່ສອດຄ້ອງກັນ. ຕົວຢ່າງຂ້າງລຸ່ມນີ້ເຊື່ອມຕໍ່ Ansible Tower ກັບ github repository ຂອງພວກເຮົາ. ເອົາໃຈໃສ່ກັບ SCM URL: ມັນອະນຸຍາດໃຫ້ທ່ານລົງທະບຽນບັນຊີເພື່ອເຊື່ອມຕໍ່ກັບບ່ອນເກັບມ້ຽນສ່ວນຕົວ, ເຊັ່ນດຽວກັນກັບລະບຸສາຂາສະເພາະ, ແທັກຫຼືຄໍາຫມັ້ນສັນຍາທີ່ຈະກວດສອບ.

ການສ້າງຂໍ້ມູນປະຈໍາຕົວສໍາລັບ ServiceNow

ດັ່ງທີ່ໄດ້ກ່າວມາ, ການຕັ້ງຄ່າໃນບ່ອນເກັບມ້ຽນຂອງພວກເຮົາບໍ່ມີຂໍ້ມູນປະຈໍາຕົວເພື່ອເຊື່ອມຕໍ່ກັບ ServiceNow ແລະບໍ່ໄດ້ລະບຸຕົວຢ່າງ ServiceNow ທີ່ພວກເຮົາຈະຕິດຕໍ່ສື່ສານ. ດັ່ງນັ້ນ, ເພື່ອກໍານົດຂໍ້ມູນນີ້, ພວກເຮົາຈະສ້າງຂໍ້ມູນປະຈໍາຕົວໃນ Ansible Tower. ອີງ​ຕາມ ເອກະສານປລັກອິນສິນຄ້າຄົງຄັງ ServiceNow, ມີຕົວແປສະພາບແວດລ້ອມຈໍານວນຫນຶ່ງທີ່ພວກເຮົາຈະກໍານົດຕົວກໍານົດການເຊື່ອມຕໍ່, ຕົວຢ່າງເຊັ່ນນີ້:

= username
    	The ServiceNow user account, it should have rights to read cmdb_ci_server (default), or table specified by SN_TABLE

    	set_via:
      	env:
      	- name: SN_USERNAME

ໃນກໍລະນີນີ້, ຖ້າຕົວແປສະພາບແວດລ້ອມ SN_USERNAME ຖືກຕັ້ງ, ປລັກອິນສິນຄ້າຄົງຄັງຈະໃຊ້ມັນເປັນບັນຊີເພື່ອເຊື່ອມຕໍ່ກັບ ServiceNow.

ພວກເຮົາຍັງຕ້ອງການກໍານົດຕົວແປ SN_INSTANCE ແລະ SN_PASSWORD.

ຢ່າງໃດກໍຕາມ, ບໍ່ມີຂໍ້ມູນປະຈໍາຕົວຂອງປະເພດນີ້ໃນ Ansible Tower ບ່ອນທີ່ທ່ານສາມາດລະບຸຂໍ້ມູນນີ້ສໍາລັບ ServiceNow. ແຕ່ Ansible Tower ອະນຸຍາດໃຫ້ພວກເຮົາກໍານົດ ປະເພດຂໍ້ມູນປະຈໍາຕົວແບບກຳນົດເອງ, ທ່ານສາມາດອ່ານເພີ່ມເຕີມກ່ຽວກັບເລື່ອງນີ້ໃນບົດຄວາມ "Ansible Tower Feature Spotlight: ຂໍ້ມູນປະຈໍາຕົວແບບກຳນົດເອງ".

ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ພວກ​ເຮົາ​, ການ​ຕັ້ງ​ຄ່າ​ການ​ປ້ອນ​ຂໍ້​ມູນ​ສໍາ​ລັບ​ການ​ກໍາ​ນົດ​ເອງ​ສໍາ​ລັບ​ການ ServiceNow ເບິ່ງ​ຄື​ດັ່ງ​ນີ້​:

fields:
  - id: SN_USERNAME
	type: string
	label: Username
  - id: SN_PASSWORD
	type: string
	label: Password
	secret: true
  - id: SN_INSTANCE
	type: string
	label: Snow Instance
required:
  - SN_USERNAME
  - SN_PASSWORD
  - SN_INSTANCE

ຂໍ້ມູນປະຈຳຕົວເຫຼົ່ານີ້ຈະຖືກເປີດເຜີຍເປັນຕົວແປສະພາບແວດລ້ອມທີ່ມີຊື່ດຽວກັນ. ນີ້ແມ່ນອະທິບາຍຢູ່ໃນການຕັ້ງຄ່າ injector:

env:
  SN_INSTANCE: '{{ SN_INSTANCE }}'
  SN_PASSWORD: '{{ SN_PASSWORD }}'
  SN_USERNAME: '{{ SN_USERNAME }}'

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ກໍານົດປະເພດໃບຢັ້ງຢືນທີ່ພວກເຮົາຕ້ອງການ, ຕອນນີ້ພວກເຮົາສາມາດເພີ່ມບັນຊີ ServiceNow ແລະກໍານົດຕົວຢ່າງ, ຊື່ຜູ້ໃຊ້ແລະລະຫັດຜ່ານເຊັ່ນນີ້:

ພວກເຮົາສ້າງສາງ

ດັ່ງນັ້ນ, ຕອນນີ້ພວກເຮົາທຸກຄົນພ້ອມທີ່ຈະສ້າງສາງໃນ Ansible Tower. ໃຫ້ໂທຫາມັນ ServiceNow:

ຫຼັງຈາກການສ້າງສາງ, ພວກເຮົາສາມາດແນບແຫຼ່ງຂໍ້ມູນໃສ່ມັນ. ໃນທີ່ນີ້ພວກເຮົາລະບຸໂຄງການທີ່ພວກເຮົາສ້າງກ່ອນຫນ້ານີ້ແລະເຂົ້າໄປໃນເສັ້ນທາງໄປຫາໄຟລ໌ສິນຄ້າຄົງຄັງ YAML ຂອງພວກເຮົາໃນບ່ອນເກັບຂໍ້ມູນການຄວບຄຸມແຫຼ່ງ, ໃນກໍລະນີຂອງພວກເຮົາມັນແມ່ນ servicenow.yml ໃນຮາກໂຄງການ. ນອກຈາກນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງເຊື່ອມຕໍ່ບັນຊີ ServiceNow ຂອງທ່ານ.

ເພື່ອກວດເບິ່ງວ່າທຸກຢ່າງເຮັດວຽກແນວໃດ, ໃຫ້ລອງຊິ້ງກັບແຫຼ່ງຂໍ້ມູນໂດຍການຄລິກທີ່ປຸ່ມ “Sync all”. ຖ້າທຸກຢ່າງຖືກຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ, ໂນດຄວນຖືກນໍາເຂົ້າເຂົ້າໄປໃນຄັງສິນຄ້າຂອງພວກເຮົາ:

ກະລຸນາຮັບຊາບວ່າກຸ່ມທີ່ພວກເຮົາຕ້ອງການກໍ່ໄດ້ຖືກສ້າງຂື້ນ.

ສະຫລຸບ

ໃນບົດຂຽນນີ້, ພວກເຮົາໄດ້ເບິ່ງວິທີການໃຊ້ plugins ສິນຄ້າຄົງຄັງຈາກການລວບລວມໃນ Ansible Tower ໂດຍໃຊ້ plugin ServiceNow ເປັນຕົວຢ່າງ. ພວກເຮົາຍັງໄດ້ລົງທະບຽນຢ່າງປອດໄພເພື່ອເຊື່ອມຕໍ່ກັບຕົວຢ່າງ ServiceNow ຂອງພວກເຮົາ. ການເຊື່ອມໂຍງ plugins ສິນຄ້າຄົງຄັງຈາກໂຄງການເຮັດວຽກບໍ່ພຽງແຕ່ກັບພາກສ່ວນທີສາມຫຼື plugins ທີ່ກໍາຫນົດເອງ, ແຕ່ຍັງສາມາດນໍາໃຊ້ເພື່ອດັດແປງການດໍາເນີນງານຂອງບາງສິນຄ້າຄົງຄັງມາດຕະຖານ. ອັນນີ້ເຮັດໃຫ້ Ansible Automation Platform ເປັນເລື່ອງງ່າຍ ແລະບໍ່ມີຮອຍຕໍ່ໃນການເຊື່ອມໂຍງກັບເຄື່ອງມືທີ່ມີຢູ່ແລ້ວເມື່ອເຮັດໃຫ້ສະພາບແວດລ້ອມ IT ທີ່ສັບສົນຂຶ້ນໂດຍອັດຕະໂນມັດ.

ທ່ານສາມາດຊອກຫາຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບຫົວຂໍ້ທີ່ສົນທະນາໃນບົດຄວາມນີ້, ເຊັ່ນດຽວກັນກັບລັກສະນະອື່ນໆຂອງການນໍາໃຊ້ Ansible, ທີ່ນີ້:

• ບລັອກໂດຍ ການບໍລິການອັດຕະໂນມັດໃນປັດຈຸບັນໂດຍໃຊ້ Ansible.
• ວິທີການສ້າງຄໍເລັກຊັນຂອງທ່ານເອງ.
• ບັນຊີລາຍຊື່ຂອງ Red Hat ສະຫນັບສະຫນູນການເກັບກໍາຢູ່ໃນເວັບໄຊທ໌ Automation Hub (cloud.redhat.com).
• Ansible Automation Platform eBooks.

*ໝວກແດງບໍ່ຮັບປະກັນວ່າລະຫັດທີ່ມີຢູ່ໃນນີ້ຖືກຕ້ອງ. ວັດສະດຸທັງໝົດແມ່ນສະໜອງໃຫ້ບົນພື້ນຖານການບໍ່ຮັບຮອງ ເວັ້ນເສຍແຕ່ໄດ້ລະບຸໄວ້ຢ່າງຈະແຈ້ງ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com