IT-omgewings word al hoe meer kompleks. In hierdie toestande is dit van kritieke belang vir die IT-outomatiseringstelsel om bygewerkte inligting te hê oor die nodusse wat in die netwerk teenwoordig is en onderhewig is aan verwerking. In die Red Hat Ansible Automation Platform word hierdie probleem opgelos deur die sogenaamde voorraad () – lyste van bestuurde nodusse.
In sy eenvoudigste vorm is voorraad 'n statiese lêer. Dit is ideaal wanneer jy met Ansible begin werk, maar namate outomatisering toeneem, word dit onvoldoende.
En hier is hoekom:
- Hoe werk jy 'n volledige lys van gemonitorde nodusse op en hou dit in stand wanneer dinge voortdurend verander, wanneer werkladings—en gevolglik die nodusse waarop hulle loop—kom en gaan?
- Hoe om die komponente van die IT-infrastruktuur te klassifiseer om spesifiek nodusse te kies vir die toepassing van 'n spesifieke outomatisering?
Dinamiese inventaris verskaf antwoorde op beide hierdie vrae () – 'n skrif of inprop wat na nodusse soek om geoutomatiseer te word, met verwysing na die bron van waarheid. Daarbenewens klassifiseer die dinamiese voorraad nodusse outomaties in groepe sodat jy teikenstelsels meer akkuraat kan kies om spesifieke Ansible-outomatisering uit te voer.
gee die Ansible-gebruiker die vermoë om toegang tot eksterne platforms te verkry om dinamies na teikennodusse te soek en hierdie platforms as 'n bron van waarheid te gebruik wanneer 'n voorraad geskep word. Die standaardlys van bronne in Ansible sluit wolkplatforms AWS EC2, Google GCP en Microsoft Azure in, en daar is ook baie ander voorraadinproppe vir Ansible.
Ansible Tower kom met 'n aantal , wat reg uit die boks werk en, benewens die wolkplatforms hierbo gelys, integrasie met VMware vCenter, Red Hat OpenStack Platform en Red Hat Satellite bied. Vir hierdie inproppe moet u net geloofsbriewe verskaf om aan die teikenplatform te koppel, waarna dit as 'n bron van voorraaddata in Ansible Tower gebruik kan word.
Benewens die standaard-inproppe wat by Ansible Tower ingesluit is, is daar ander voorraadinproppe wat deur die Ansible-gemeenskap ondersteun word. Met die oorgang na hierdie inproppe het begin om in die ooreenstemmende versamelings ingesluit te word.
In hierdie pos sal ons 'n voorbeeld neem van die werk met die voorraadinprop vir ServiceNow, 'n gewilde IT-diensbestuurplatform waarin kliënte dikwels inligting oor al hul toestelle in die CMDB stoor. Daarbenewens kan die CMDB konteks bevat wat nuttig is vir outomatisering, soos inligting oor bedienereienaars, diensvlakke (produksie/nie-produksie), geïnstalleerde opdaterings en onderhoudsvensters. Die Ansible-inventaris-inprop kan saam met ServiceNow CMDB werk en is deel van die versameling op die portaal .
Git-bewaarplek
Om 'n voorraadinprop uit 'n versameling in Ansible Tower te gebruik, moet dit as die projekbron gestel word. In Ansible Tower is 'n projek 'n integrasie met 'n soort weergawebeheerstelsel, soos 'n git-bewaarplek, wat gebruik kan word om nie net outomatiseringsspeelboeke te sinchroniseer nie, maar ook veranderlikes en voorraadlyste.
Ons bewaarplek is eintlik baie eenvoudig:
├── collections
│ └── requirements.yml
└── servicenow.yml
Die servicenow.yml-lêer bevat besonderhede vir die inprop-inventaris. In ons geval spesifiseer ons eenvoudig die tabel in die ServiceNow CMDB wat ons wil gebruik. Ons stel ook die velde in wat as nodusveranderlikes bygevoeg sal word, plus sekere inligting oor die groepe wat ons wil skep.
$ 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: ''
Neem asseblief kennis dat dit nie die ServiceNow-instansie spesifiseer waaraan ons op enige manier sal koppel nie, en nie enige geloofsbriewe vir verbinding spesifiseer nie. Ons sal dit alles later in Ansible Tower konfigureer.
benodig sodat Ansible Tower die vereiste versameling kan aflaai en daardeur die vereiste voorraadinprop kan verkry. Andersins sal ons hierdie versameling handmatig op al ons Ansible Tower-nodusse moet installeer en onderhou.
$ cat collections/requirements.yml
---
collections:
- name: servicenow.servicenow
Sodra ons hierdie konfigurasie na weergawebeheer gedruk het, kan ons 'n projek in Ansible Tower skep wat na die ooreenstemmende bewaarplek verwys. Die voorbeeld hieronder koppel Ansible Tower na ons github-bewaarplek. Gee aandag aan die SCM-URL: dit laat jou toe om 'n rekening te registreer om aan 'n private bewaarplek te koppel, asook om 'n spesifieke tak, merker of commit te spesifiseer om uit te betaal.
Skep geloofsbriewe vir ServiceNow
Soos genoem, bevat die konfigurasie in ons bewaarplek nie geloofsbriewe om aan ServiceNow te koppel nie en spesifiseer nie die ServiceNow-instansie waarmee ons sal kommunikeer nie. Daarom, om hierdie data te stel, sal ons geloofsbriewe in Ansible Tower skep. Volgens , is daar 'n aantal omgewingsveranderlikes waarmee ons die verbindingsparameters sal stel, byvoorbeeld, soos volg:
= 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 hierdie geval, as die SN_USERNAME omgewingsveranderlike gestel is, sal die voorraadinprop dit as 'n rekening gebruik om aan ServiceNow te koppel.
Ons moet ook die SN_INSTANCE en SN_PASSWORD veranderlikes stel.
Daar is egter geen geloofsbriewe van hierdie tipe in Ansible Tower waar jy hierdie data vir ServiceNow kan spesifiseer nie. Maar Ansible Tower laat ons toe om te definieer , jy kan meer hieroor lees in die artikel .
In ons geval lyk die invoerkonfigurasie vir pasgemaakte geloofsbriewe vir ServiceNow soos volg:
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
Hierdie geloofsbriewe sal blootgestel word as omgewingsveranderlikes met dieselfde naam. Dit word beskryf in die inspuiterkonfigurasie:
env:
SN_INSTANCE: '{{ SN_INSTANCE }}'
SN_PASSWORD: '{{ SN_PASSWORD }}'
SN_USERNAME: '{{ SN_USERNAME }}'
Dus, ons het die tipe geloofsbriewe wat ons benodig gedefinieer, nou kan ons 'n ServiceNow-rekening byvoeg en die instansie, gebruikersnaam en wagwoord soos volg instel:
Ons skep voorraad
So, nou is ons almal gereed om 'n voorraad in Ansible Tower te skep. Kom ons noem dit ServiceNow:
Nadat ons die voorraad geskep het, kan ons 'n databron daaraan heg. Hier spesifiseer ons die projek wat ons vroeër geskep het en voer die pad na ons YAML-inventarislêer in die bronbeheerbewaarplek in, in ons geval is dit servicenow.yml in die projekwortel. Daarbenewens moet jy jou ServiceNow-rekening koppel.
Om te kyk hoe alles werk, kom ons probeer om met die databron te sinchroniseer deur op die "Sinkroniseer alles"-knoppie te klik. As alles korrek opgestel is, moet die nodusse in ons voorraad ingevoer word:
Neem asseblief kennis dat die groepe wat ons benodig ook geskep is.
Gevolgtrekking
In hierdie pos het ons gekyk na hoe om voorraadinproppe van versamelings in Ansible Tower te gebruik deur die ServiceNow-inprop as voorbeeld te gebruik. Ons het ook geloofsbriewe veilig geregistreer om aan ons ServiceNow-instansie te koppel. Om 'n voorraadinprop vanaf 'n projek te koppel, werk nie net met derdeparty- of pasgemaakte inproppe nie, maar kan ook gebruik word om die werking van sommige standaardvoorraad te verander. Dit maak Ansible Automation Platform maklik en naatloos om met bestaande gereedskap te integreer wanneer toenemend komplekse IT-omgewings outomatiseer word.
U kan meer inligting vind oor die onderwerpe wat in hierdie pos bespreek word, sowel as ander aspekte van die gebruik van Ansible, hier:
- Blog deur .
- .
- Lys van Red Hat-ondersteunde versamelings op die Automation Hub-webwerf ().
- .
*Red Hat waarborg geen waarborg dat die kode hierin vervat korrek is nie. Alle materiaal word verskaf op 'n nie-endossement basis tensy anders uitdruklik vermeld.
Bron: will.com