ІТ-асяроддзя становяцца ўсё складаней і складаней. У гэтых умовах для сістэмы ІТ-аўтаматызацыі крытычна важна мець актуальную інфармацыю аб вузлах, якія прысутнічаюць у сетцы і падлягаюць апрацоўцы. У 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