ІТ-середовища стають все складнішими і складнішими. У цих умовах для системи ІТ-автоматизації критично важливо мати актуальну інформацію про вузли, які є в мережі та підлягають обробці. У Red Hat Ansible Automation Platform це питання вирішується через так звані інвентори () - Списки керованих вузлів.
У своїй простій формі інвентори є статичний файл. Це ідеальний варіант, коли ви починаєте працювати з Ansible, але в міру розширення автоматизації його стає недостатньо.
І ось чому:
- Як оновлювати та підтримувати в актуальному стані повний список контрольованих вузлів, коли щось постійно змінюється, коли робочі навантаження – а за ними і вузли, на яких вони виконуються – то виникають, то зникають?
- Як класифікувати компоненти ІТ-інфраструктури, щоб прицільно вибирати вузли для застосування тієї чи іншої автоматизації?
Відповіді на обидва ці питання дає динамічний інвентор () – скрипт або плагін, який шукає вузли, що підлягають автоматизації, звертаючись до джерела істини (source of truth). Крім того, динамічний інвентор автоматично класифікує вузли по групах, щоб ви могли точніше відбирати цільові системи для виконання тієї чи іншої автоматизації 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. З переходом на ці плагіни стали включатись у відповідні колекції.
У цьому пості ми для прикладу розберемо роботу з інвентором-плагіном для ServiceNow, популярної платформи управління ІТ-сервісами, в CMDB якої замовники часто зберігають відомості про всі свої пристрої. Крім того, CMDB може містити корисний для автоматизації контекст, наприклад, відомості про власників серверів, рівні обслуговування (production/non-production), встановлені оновлення та вікна технічного обслуговування. Інвентори-плагін Ansible вміє працювати з CMDB ServiceNow та входить до складу колекції на порталі .
Git-репозиторій
Щоб використовувати в Ansible Tower інвентори-плагін із колекції, його треба задати як джерело проекту. У Ansible Tower проект – це інтеграція з якоюсь системою керування версіями, на кшталт репозиторію git, яку можна використовувати для синхронізації не тільки плейбуків автоматизації, а й змінних, а також списків інвенторів.
Наш репозиторій насправді дуже простий:
├── collections
│ └── requirements.yml
└── servicenow.yml
Файл servicenow.yml містить подробиці для інвенторів плагіна. У нашому випадку ми просто вказуємо таблицю CMDB ServiceNow, яку хочемо використовувати. А також задаємо поля, які будуть додаватися як змінні вузли, плюс певну інформацію щодо груп, які хочемо створити.
$ 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.
потрібен для того, щоб Ansible Tower міг завантажити потрібну колекцію і отримати тим самим потрібний інвентор-плагін. Інакше довелося б вручну встановлювати та підтримувати цю колекцію на всіх наших вузлах Ansible Tower.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Після того, як ми відправили цю конфігурацію в систему контролю версій, Ansible Tower можна створювати проект, що посилається на відповідний репозиторій. У прикладі нижче Ansible Tower узгоджується з нашим репозиторієм на github. Зверніть увагу на SCM URL: він дозволяє прописати обліковий запис для підключення до приватного репозиторію, а також встановити конкретну гілку, мітку або коміт для вилучення.
Створюємо credentials для ServiceNow
Як уже говорилося, конфігурація в нашому репозиторії не містить облікових даних для підключення до ServiceNow і не конкретизує інстанс ServiceNow, з яким ми спілкуватимемося. Тому для завдання цих даних ми створимо credentials в Ansible Tower. Згідно , існує ряд змінних оточення, за допомогою яких ми і задамо параметри підключення, наприклад, так:
= 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 немає credentials такого типу, де можна було б вказати ці дані для ServiceNow. Натомість Ansible Tower дозволяє нам визначати , докладніше про це можна почитати у статті .
У нашому випадку input-конфігурація для настроєних credentials для 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
Ці credentials будуть експонуватися як змінні оточення з тим же ім'ям. Це описується в конфігурації injector-а:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Отже, ми визначили потрібний нам тип credential, тепер можна додати обліковий запис ServiceNow і задати інстанс, ім'я користувача та пароль, ось так:
Створюємо інвентори
Отже, тепер у нас все готове створити інвентори в Ansible Tower. Назвемо його ServiceNow:
Після створення інвенторів ми можемо прикріпити до неї джерело даних. Тут ми вказуємо проект, який створили раніше, і вводимо шлях до нашого інвентору-файлу YAML у репозиторії системи керування версіями, у нашому випадку це servicenow.yml у корені проекту. Крім того, треба прив'язати обліковий запис ServiceNow.
Щоб перевірити, як усе працює, спробуємо синхронізуватись із джерелом даних, натиснувши кнопку «Sync all». Якщо все налаштовано правильно, то вузли мають імпортуватися до нашого інвентору:
Зверніть увагу, що необхідні нам групи також створилися.
Висновок
У цьому пості ми розглянули, як у Ansible Tower використовувати інвентори-плагіни з колекцій на прикладі плагіна ServiceNow. Ми також безпечно прописали облікові дані для підключення до нашого інстансу ServiceNow. Прив'язка інвенторів-плагінів з проекту працює не тільки зі сторонніми або плагінами, що настроюються, але і цілком може застосовуватися для модифікації роботи деяких штатних інвенторів. Завдяки цьому Ansible Automation Platform легко та безшовно інтегрується з існуючими інструментами при автоматизації ІТ-середовищ, які стають дедалі складнішими.
Знайти додаткові відомості з розглянутих у цьому посту тем, а також інших аспектів застосування Ansible можна тут:
- Блог по .
- .
- Список підтримуваних Red Hat колекцій на сайті Automation Hub ().
- .
*Red Hat не дає жодних гарантій коректності наведеного тут коду. Усі матеріали надаються на умовах відсутності підтримки, якщо тільки інше не заявлено у явному вигляді.
Джерело: habr.com