Paggamit ng mga plugin ng imbentaryo mula sa Ansible Content Collections sa Ansible Tower

Ang mga kapaligiran sa IT ay nagiging mas kumplikado. Sa mga kundisyong ito, kritikal para sa IT automation system na magkaroon ng up-to-date na impormasyon tungkol sa mga node na nasa network at napapailalim sa pagproseso. Sa Red Hat Ansible Automation Platform, naresolba ang isyung ito sa pamamagitan ng tinatawag na imbentaryo (imbentaryo) – mga listahan ng mga pinamamahalaang node.

Sa pinakasimpleng anyo nito, ang imbentaryo ay isang static na file. Tamang-tama ito kapag nagsimula kang magtrabaho sa Ansible, ngunit habang tumataas ang automation, nagiging hindi ito sapat.

At dito ang dahilan kung bakit:

1. Paano mo i-a-update at pinapanatili ang kumpletong listahan ng mga sinusubaybayang node kapag ang mga bagay ay patuloy na nagbabago, kapag ang mga workload—at pagkatapos ang mga node na pinapatakbo nila—ay darating at umalis?
2. Paano pag-uri-uriin ang mga bahagi ng imprastraktura ng IT upang partikular na pumili ng mga node para sa paglalapat ng isang partikular na automation?

Ang dinamikong imbentaryo ay nagbibigay ng mga sagot sa parehong tanong na ito (dynamic na imbentaryo) – isang script o plugin na naghahanap ng mga node na automated, na tumutukoy sa pinagmulan ng katotohanan. Bilang karagdagan, ang dynamic na imbentaryo ay awtomatikong nag-uuri ng mga node sa mga pangkat upang mas tumpak kang pumili ng mga target na system para sa pagsasagawa ng partikular na Ansible automation.

Mga plugin ng imbentaryo bigyan ang Ansible user ng kakayahang mag-access ng mga panlabas na platform upang dynamic na maghanap ng mga target na node at gamitin ang mga platform na ito bilang pinagmumulan ng katotohanan kapag gumagawa ng imbentaryo. Kasama sa karaniwang listahan ng mga source sa Ansible ang mga cloud platform na AWS EC2, Google GCP at Microsoft Azure, at marami ring iba pang plugin ng imbentaryo para sa Ansible.

Ang Ansible Tower ay may kasamang ilang mga plugin ng imbentaryo, na gumagana sa labas ng kahon at, bilang karagdagan sa mga cloud platform na nakalista sa itaas, ay nagbibigay ng integrasyon sa VMware vCenter, Red Hat OpenStack Platform at Red Hat Satellite. Para sa mga plugin na ito, kailangan mo lang magbigay ng mga kredensyal upang kumonekta sa target na platform, pagkatapos nito ay magagamit ang mga ito bilang pinagmumulan ng data ng imbentaryo sa Ansible Tower.

Bilang karagdagan sa mga karaniwang plugin na kasama sa Ansible Tower, may iba pang mga plugin ng imbentaryo na sinusuportahan ng komunidad ng Ansible. Sa paglipat sa Red Hat Ansible Content Collections nagsimulang isama ang mga plugin na ito sa kaukulang mga koleksyon.

Sa post na ito, kukuha kami ng halimbawa ng pagtatrabaho sa plugin ng imbentaryo para sa ServiceNow, isang sikat na platform ng pamamahala ng serbisyo sa IT kung saan madalas na nag-iimbak ang mga customer ng impormasyon tungkol sa lahat ng kanilang device sa CMDB. Bilang karagdagan, ang CMDB ay maaaring maglaman ng konteksto na kapaki-pakinabang para sa automation, tulad ng impormasyon tungkol sa mga may-ari ng server, mga antas ng serbisyo (produksyon/di-produksyon), mga naka-install na update, at mga window ng pagpapanatili. Maaaring gumana ang Ansible inventory plugin sa ServiceNow CMDB at bahagi ito ng koleksyon serbisyo ngayon sa portal galaxy.ansible.com.

Git repository

Upang gumamit ng plugin ng imbentaryo mula sa isang koleksyon sa Ansible Tower, dapat itong itakda bilang pinagmulan ng proyekto. Sa Ansible Tower, ang isang proyekto ay isang integrasyon sa ilang uri ng version control system, tulad ng git repository, na maaaring gamitin upang i-synchronize hindi lamang ang mga automation playbook, kundi pati na rin ang mga variable at listahan ng imbentaryo.

Ang aming imbakan ay talagang napaka-simple:

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

Ang servicenow.yml file ay naglalaman ng mga detalye para sa imbentaryo ng plugin. Sa aming kaso, tinukoy lang namin ang talahanayan sa ServiceNow CMDB na gusto naming gamitin. Itinakda rin namin ang mga field na idaragdag bilang mga variable ng node, kasama ang ilang partikular na impormasyon sa mga pangkat na gusto naming gawin.

$ 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: ''

Pakitandaan na hindi nito tinukoy ang instance ng ServiceNow kung saan kami magkokonekta sa anumang paraan, at hindi tumutukoy ng anumang mga kredensyal para sa koneksyon. I-configure namin ang lahat ng ito mamaya sa Ansible Tower.

File collections/requirements.yml kinakailangan upang ma-download ng Ansible Tower ang kinakailangang koleksyon at sa gayon ay makuha ang kinakailangang plugin ng imbentaryo. Kung hindi, kailangan naming manu-manong i-install at panatilihin ang koleksyong ito sa lahat ng aming Ansible Tower node.

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

- name: servicenow.servicenow

Kapag nai-push na namin ang configuration na ito sa version control, makakagawa kami ng proyekto sa Ansible Tower na tumutukoy sa kaukulang repository. Ang halimbawa sa ibaba ay nagli-link ng Ansible Tower sa aming github repository. Bigyang-pansin ang URL ng SCM: pinapayagan ka nitong magrehistro ng isang account upang kumonekta sa isang pribadong repositoryo, pati na rin tukuyin ang isang partikular na sangay, tag o commit na tingnan.

Paglikha ng mga kredensyal para sa ServiceNow

Gaya ng nabanggit, ang configuration sa aming repository ay hindi naglalaman ng mga kredensyal upang kumonekta sa ServiceNow at hindi tumutukoy sa ServiceNow instance kung saan kami makikipag-usap. Samakatuwid, para itakda ang data na ito, gagawa kami ng mga kredensyal sa Ansible Tower. Ayon kay Dokumentasyon ng plugin ng imbentaryo ng ServiceNow, mayroong isang bilang ng mga variable ng kapaligiran kung saan itatakda namin ang mga parameter ng koneksyon, halimbawa, tulad nito:

= 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

Sa kasong ito, kung nakatakda ang SN_USERNAME na environment variable, gagamitin ito ng plugin ng imbentaryo bilang account para kumonekta sa ServiceNow.

Kailangan din nating itakda ang mga variable na SN_INSTANCE at SN_PASSWORD.

Gayunpaman, walang mga kredensyal ng ganitong uri sa Ansible Tower kung saan maaari mong tukuyin ang data na ito para sa ServiceNow. Ngunit pinapayagan tayo ng Ansible Tower na tukuyin mga uri ng custom na kredensyal, maaari mong basahin ang higit pa tungkol dito sa artikulo "Ansible Tower Feature Spotlight: Mga Custom na Kredensyal".

Sa aming kaso, ganito ang hitsura ng configuration ng input para sa mga custom na kredensyal para sa 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

Ang mga kredensyal na ito ay malalantad bilang mga variable ng kapaligiran na may parehong pangalan. Ito ay inilarawan sa pagsasaayos ng injector:

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

Kaya, tinukoy namin ang uri ng kredensyal na kailangan namin, ngayon ay maaari kaming magdagdag ng isang ServiceNow account at itakda ang halimbawa, username at password, tulad nito:

Lumilikha kami ng imbentaryo

Kaya, ngayon handa na tayong lahat na gumawa ng imbentaryo sa Ansible Tower. Tawagan natin itong ServiceNow:

Pagkatapos gawin ang imbentaryo, maaari kaming mag-attach ng data source dito. Dito namin tinukoy ang proyekto na ginawa namin nang mas maaga at ipasok ang landas sa aming YAML file ng imbentaryo sa source control repository, sa aming kaso ito ay servicenow.yml sa root ng proyekto. Bilang karagdagan, kailangan mong i-link ang iyong ServiceNow account.

Upang tingnan kung paano gumagana ang lahat, subukan nating mag-synchronize sa data source sa pamamagitan ng pag-click sa button na “I-sync lahat”. Kung ang lahat ay na-configure nang tama, ang mga node ay dapat na ma-import sa aming imbentaryo:

Pakitandaan na ang mga pangkat na kailangan namin ay nalikha na rin.

Konklusyon

Sa post na ito, tiningnan namin kung paano gumamit ng mga plugin ng imbentaryo mula sa mga koleksyon sa Ansible Tower gamit ang ServiceNow plugin bilang isang halimbawa. Ligtas din kaming nagrehistro ng mga kredensyal para kumonekta sa aming ServiceNow instance. Ang pag-link ng plugin ng imbentaryo mula sa isang proyekto ay gumagana hindi lamang sa mga third-party o custom na plugin, ngunit maaari ding gamitin upang baguhin ang pagpapatakbo ng ilang karaniwang mga imbentaryo. Ginagawa nitong madali at tuluy-tuloy ang Ansible Automation Platform na isama sa mga umiiral nang tool kapag nag-automate ng mas kumplikadong mga IT environment.

Makakahanap ka ng higit pang impormasyon sa mga paksang tinalakay sa post na ito, pati na rin ang iba pang aspeto ng paggamit ng Ansible, dito:

• Blog ni Automating ServiceNow gamit ang Ansible.
• Paano lumikha ng iyong sariling mga koleksyon.
• Listahan ng mga suportadong koleksyon ng Red Hat sa website ng Automation Hub (cloud.redhat.com).
• Mga eBook ng Ansible Automation Platform.

*Hindi tinitiyak ng Red Hat na tama ang code na nakapaloob dito. Ang lahat ng mga materyales ay ibinibigay sa batayan ng hindi pag-endorso maliban kung hayagang nakasaad.

Pinagmulan: www.habr.com