Използване на добавки за инвентар от Ansible Content Collections в Ansible Tower

ИТ средите стават все по-сложни. В тези условия е критично за ИТ системата за автоматизация да разполага с актуална информация за възлите, които присъстват в мрежата и подлежат на обработка. В Red Hat Ansible Automation Platform този проблем е решен чрез така наречената инвентаризация (опис) – списъци с управлявани възли.

В най-простата си форма инвентарът е статичен файл. Това е идеално, когато започнете да работите с Ansible, но с нарастването на автоматизацията става недостатъчно.

Ето защо:

1. Как актуализирате и поддържате пълен списък на наблюдаваните възли, когато нещата непрекъснато се променят, когато работните натоварвания — и впоследствие възлите, върху които работят — идват и си отиват?
2. Как да класифицираме компонентите на ИТ инфраструктурата, за да изберем конкретно възли за прилагане на определена автоматизация?

Динамичната инвентаризация дава отговори и на двата въпроса (динамична инвентаризация) – скрипт или плъгин, който търси възли за автоматизиране, като се позовава на източника на истината. В допълнение, динамичният инвентар автоматично класифицира възлите в групи, така че да можете по-точно да изберете целеви системи за извършване на специфична автоматизация на Ansible.

Плъгини за инвентаризация дават на потребителя на Ansible възможността за достъп до външни платформи за динамично търсене на целеви възли и използване на тези платформи като източник на истина при създаване на инвентар. Стандартният списък с източници в Ansible включва облачни платформи AWS EC2, Google GCP и Microsoft Azure, а има и много други добавки за инвентаризация за Ansible.

Ansible Tower идва с редица плъгини за инвентаризация, които работят направо от кутията и в допълнение към облачните платформи, изброени по-горе, осигуряват интеграция с VMware vCenter, Red Hat OpenStack Platform и Red Hat Satellite. За тези плъгини трябва само да предоставите идентификационни данни за свързване с целевата платформа, след което те могат да се използват като източник на данни за инвентара в Ansible Tower.

В допълнение към стандартните добавки, включени в Ansible Tower, има други добавки за инвентар, поддържани от общността на Ansible. С прехода към Колекции от съдържание Ansible на Red Hat тези добавки започнаха да се включват в съответните колекции.

В тази публикация ще вземем пример за работа с плъгина за инвентаризация за ServiceNow, популярна платформа за управление на ИТ услуги, в която клиентите често съхраняват информация за всички свои устройства в CMDB. В допълнение, CMDB може да съдържа контекст, който е полезен за автоматизация, като информация за собствениците на сървъри, нива на обслужване (производствени/непроизводствени), инсталирани актуализации и периоди за поддръжка. Приставката за инвентаризация Ansible може да работи със ServiceNow CMDB и е част от колекцията обслужване на портала galaxy.ansible.com.

Git хранилище

За да използвате плъгин за инвентар от колекция в Ansible Tower, той трябва да бъде зададен като източник на проекта. В Ansible Tower проектът е интеграция с някакъв вид система за контрол на версиите, като git хранилище, което може да се използва за синхронизиране не само на книги за автоматизация, но и на променливи и списъци с инвентар.

Нашето хранилище всъщност е много просто:

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

Файлът servicenow.yml съдържа подробности за инвентара на плъгина. В нашия случай ние просто посочваме таблицата в ServiceNow CMDB, която искаме да използваме. Ние също задаваме полетата, които ще бъдат добавени като променливи на възел, плюс определена информация за групите, които искаме да създадем.

$ 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 да изтегли необходимата колекция и по този начин да получи необходимия плъгин за инвентар. В противен случай ще трябва ръчно да инсталираме и поддържаме тази колекция на всички наши възли на Ansible Tower.

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

- name: servicenow.servicenow

След като прехвърлим тази конфигурация към контрола на версиите, можем да създадем проект в Ansible Tower, който препраща към съответното хранилище. Примерът по-долу свързва Ansible Tower с нашето хранилище в github. Обърнете внимание на 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: Персонализирани идентификационни данни“.

В нашия случай входната конфигурация за персонализирани идентификационни данни за 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

Тези идентификационни данни ще бъдат изложени като променливи на средата със същото име. Това е описано в конфигурацията на инжектора:

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

И така, дефинирахме типа идентификационни данни, от който се нуждаем, сега можем да добавим акаунт в ServiceNow и да зададем потребителското име и паролата, както следва:

Ние създаваме инвентар

И така, сега всички сме готови да създадем инвентар в Ansible Tower. Нека го наречем ServiceNow:

След като създадем инвентара, можем да прикачим източник на данни към него. Тук посочваме проекта, който създадохме по-рано, и въвеждаме пътя до нашия YAML инвентарен файл в хранилището за контрол на източника, в нашия случай това е servicenow.yml в корена на проекта. Освен това трябва да свържете своя акаунт в ServiceNow.

За да проверите как работи всичко, нека се опитаме да синхронизираме с източника на данни, като щракнете върху бутона „Синхронизиране на всички“. Ако всичко е конфигурирано правилно, тогава възлите трябва да бъдат импортирани в нашия инвентар:

Моля, имайте предвид, че групите, от които се нуждаем, също са създадени.

Заключение

В тази публикация разгледахме как да използваме плъгини за инвентар от колекции в Ansible Tower, използвайки плъгина ServiceNow като пример. Ние също така сигурно регистрирахме идентификационни данни за свързване с нашия екземпляр на ServiceNow. Свързването на плъгин за инвентаризация от проект работи не само с плъгини на трети страни или персонализирани плъгини, но може да се използва и за промяна на работата на някои стандартни инвентаризации. Това прави Ansible Automation Platform лесна и безпроблемна за интегриране със съществуващи инструменти при автоматизиране на все по-сложни ИТ среди.

Можете да намерите повече информация относно темите, обсъждани в тази публикация, както и други аспекти на използването на Ansible, тук:

• Блог от Автоматизиране на ServiceNow с помощта на Ansible.
• Как да създадете свои собствени колекции.
• Списък на колекциите, поддържани от Red Hat, на уебсайта на Automation Hub (cloud.redhat.com).
• Електронни книги на Ansible Automation Platform.

*Red Hat не гарантира, че съдържащият се тук код е правилен. Всички материали се предоставят без одобрение, освен ако изрично не е посочено друго.

Източник: www.habr.com