Usura inventarii plugins ex Ansible Collections in Ansible turrim

IT ambitus magis magisque implicati fiunt. His conditionibus, criticum est pro IT systema automationis habere notitias recentes de nodis, quae in retis et processus subiciuntur. In Rubro Hat Ansible Platform Automation, haec quaestio per inventarium sic dictum resolvitur.inventarium) — Tabulae nodis tractatae.

Inventarium in forma simplicissima est fasciculus static. Hoc specimen est cum apud Ansible operari incipis, sed ut automatio augetur, fit insufficiens.

Ecce quare,

1. Quomodo tu renovas et servas indicem nodis monitoriis cum res continenter mutantur, cum laboribus — et postea nodis currunt — veniunt et eunt?
2. Quomodo elementa infrastructurae IT referendae sunt ut nodos selectos specifice ad aliquam automationem applicandam?

Inventarium dynamicum praebet responsiones ad utramque harum quaestionum (dynamic inventory) - scriptionem vel plugin quaerentibus nodis automated, referendo ad fontem veritatis. Praeterea inventarium dynamicum automatice nodos in circulos classificat, ut accuratius rationes scopum eligere possis ad automationem specificam Ansible perficiendam.

Inventarium plugins da Ansible user facultatem accessiendi extra suggesta ad nodos scopum dynamice quaerendi ac his suggestis utendi tamquam fons veritatis in inventario creando. Numerus fontium in Ansible includunt suggesta nubes AWS EC2, Google GCP et Microsoft Azure, et multae praeterea sunt plugins inventarii in Ansible.

Ansible Turrim venit cum multis inventarium pluginsquae ex arca elaborant et, praeter tabulata supra posita nubes, integrationem praebent cum VMware vCenter, Red Hat OpenStack Platform et Red Hat Satellite. Ad haec plugina, solum documentorum praebere debes ad suggestum scopo coniungendum, quo uti possunt ut fons inventarii notitiarum in Turri Ansible.

Praeter vexillum plugins inclusa cum Turri Ansible, alia sunt plugins inventarii communitati Ansible suffulta. Cum transitus ad Red Hat Ansible Content Collections Haec plugina includi coeperunt in collectionibus respondentibus.

In hoc poste exemplum dabimus operandi cum inventario plugin pro ServiceNow, popularis IT servitii administratione tribunali in quo clientes saepe informationes de omnibus eorum machinis in CMDB condunt. Praeterea CMDB potest continere contextum ad automationem utilem, ut informationes de servitoribus dominis, servitii gradus (productionis/non-productionis), updates inauguratus, et fenestras sustentationes. Pluginum inventarium Ansible cum ServiceNow CMDB laborare potest et collectionis pars est nunc opera in portal galaxy.ansible.com.

git repositio

Ut plugin inventario utatur ex collectione in Turri Ansible, debet tamquam fons documenti apponi. In Turri Ansible, consilium est integratio cum quodam genere versionis ratio ditionis, sicut git repositorium, quod adhiberi potest non solum automationis fabularum librorum, sed etiam variabiles et inventarii indices synchronizare.

Repositorium nostrum valde simplex est;

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

Documentum servitii.yml fasciculus singula continet pro inventario plugin. In nobis, mensam simpliciter denotamus in ServiceNow CMDB qua uti volumus. Agros etiam constituimus, qui variabiles nodi accedunt, plus certa informationes in coetibus quas creare volumus.

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

Nota quaeso hanc instantiam non specificare ServiceNow, ad quod nullo modo coniungemus, nec documentorum nexum designat. Haec omnia postea in Ansible turri configurabimus.

Fasciculi collectiones/requirements.yml opus ut Ansible Turris collectionem debitam extrahere possit ac per hoc plugin inventarii requisitam obtineat. Alioquin manually instituere volumus et hanc collectionem in omnibus arcis Ansible nodis nostris conservare.

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

- name: servicenow.servicenow

Cum hanc configurationem ad imperium versionis impulimus, consilium in Turri Ansible quod respondente repositorio designatum creare possumus. Exemplum infra nexus Ansible turrim ad github repositorium nostrum. Animadverte ad SCM URL: permittit te rationem subcriptio coniungi cum repositorio privato, necnon ramum specificum, tag vel mandare de reprimendo.

Creando documentorum pro ServiceNow

Ut dictum, figuratio in promptuario nostro documentorum non continet nectere ad ServiceNow, nec speciem servitii designat cum qua communicabimus. Ergo ut haec notitia ponatur, documentorum in Turri Ansible creabimus. Secundum ServiceNow inventarium plugin documentasunt plures variabiles ambitus, quibus nexum parametri ponemus, exempli gratia, hoc modo:

= 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

In hoc casu, si ambitus variabilis SN_USERNAME positus est, plugin inventario ea ratione utetur ad coniungere ad ServiceNow.

Etiam opus est ut variabiles SN_INSTANCE et SN_PASSWORD constituantur.

Nihilominus documenta huius generis nulla sunt in Turri Ansible ubi hanc datam pro ServiceNow exprimere potuisti. Sed Ansible turrim definire nobis permittit consuetudo documentorum generum, plura de hoc legere potes in articulo "Ansible Tower Feature Spotlight: Custom Credentials".

In casu nostro, initus configurationis pro documentorum consuetudinum pro ServiceNow sic apparet:

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

Haec documentorum in ambitu variabilium eodem nomine patebunt. Hoc in injectore configuratione describitur:

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

Itaque genus documentorum quo indigemus definivimus, nunc ServiceNow rationem addere possumus atque instantia, username et password, haec sunt:

Nos creare inventarium

Ita nunc omnes parati sumus inventarium in Turri Ansible creare. Vocemus ServiceNow:

Post inventarium creando, fons notitiae nostrae ei adnectere possumus. Hic designamus consilium quod prius creatum est et iter ad inventarii nostri YAML fasciculi in fonte repositorio moderante, in nostro casu est inserviens.yml in radice proiecti. Praeterea opus est tibi tuam ServiceNow rationem.

Sisto quomodo omnia opera, conemur congruere cum fonte datae strepitando "Sync omnia" conjunctionem. Si omnia recte configurantur, nodi in inventarium nostrum importari debent;

Quaeso nota quod coetus quibus indigemus etiam creatos esse.

conclusio,

In hoc poste, inspeximus quomodo inventarium plugins ex collectionibus in Turre Ansible utendo in ServiceNow plugin sicut exemplum. Etiam documentorum descripserunt secure cum ServiceNow exempli gratia coniungere. Plugini inventarii ex opera projecti colligatio non solum cum plugins tertia factione vel consuetudine, sed etiam ad operationem alicuius normae inventarii modificandam adhiberi potest. Hoc facit Ansible Automation Platform facilem et inconsutilis ut instrumenta exsistentia integrare cum automando magis intricatas IT ambitus efficiat.

Plura invenire potes de locis in hac statione agitatis, ac alias rationes utendi Ansible, hic:

• Blog by Automating ServiceNow usura Ansible.
• Quam creare tua collections.
• Index Red Hat suscepit collectionibus in Automation Hub website (cloud.redhat.com).
• Ansible Automation Platform eBooks.

*Red Hat nihil facit spondeum quod in codice continetur is correct. Omnia materiae praebentur fundamento non assentiente, nisi aliud expresse caveatur.

Source: www.habr.com