ИТ средите стават все по-сложни. При тези условия, за системата за ИТ автоматизация е критично важно да има актуална информация за възлите, които присъстват в мрежата и подлежат на обработка. В 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 може да съдържа полезен контекст за автоматизация, например, данни за собствениците на сървъри, нива на обслужване (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: той позволява да зададете акаунт за свързване с частно хранилище, а също така да зададете конкретен клон, етикет или комит за извличане.
Създаваме удостоверения за ServiceNow
Както вече бе споменато, конфигурацията в нашето хранилище не съдържа удостоверения за свързване с ServiceNow и не уточнява инстанса на ServiceNow, с който ще комуникираме. Затова, за да зададем тези данни, ще създадем удостоверения в 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 няма удостоверения от този тип, където можем да зададем тези данни за ServiceNow. Но Ansible Tower ни позволява да определяме , за повече информация можете да прочетете статията .
В нашия случай входната конфигурация за персонализирани удостоверения за ServiceNow изглежда по следния начин:
fields:
- id: SN_USERNAME
type: string
label: Потребителско име
- id: SN_PASSWORD
type: string
label: Парола
secret: true
- id: SN_INSTANCE
type: string
label: Instance на Snow
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.
За да проверим как работи всичко, ще се опитаме да синхронизираме с източника на данни, натискайки бутона „Sync all“. Ако всичко е настроено правилно, възлите трябва да се импортират в нашия инвентори:
Обърнете внимание, че необходимите групи също бяха създадени.
Заключение
В този пост разгледахме как да използваме инвентори плъгини от колекции в Ansible Tower на примера на плъгина ServiceNow. Също така безопасно написахме данните за вход за свързване с нашия инстанс на ServiceNow. Свързването на инвентори плъгин от проекта работи не само с външни или настройваеми плъгини, но и може да се прилага за модификация на работата на някои стандартни инвентори. Благодарение на това Ansible Automation Platform лесно и безпроблемно се интегрира с вече съществуващите инструменти при автоматизация на ИТ-средите, които стават все по-сложни.
Можете да намерите допълнителна информация по темите, разгледани в този пост, както и по други аспекти на използването на Ansible тук:
- Блог за .
- .
- Списък на поддържаните колекции на Red Hat на сайта Automation Hub ().
- .
*Red Hat не предоставя никакви гаранции за правилността на кода, приведен тук. Всички материали се предоставят без поддръжка, освен ако не е посочено изрично друго.
Източник: habr.com
