Sám jsem příznivcem CLI a při práci s Ansible na něj nedám dopustit. Ovšem ne každý ocení jednoduchost tohoto rozhraní. Poslední dobou narážím právě na zákazníky tohoto typu a bylo tedy potřeba přijít s něčím, co bude mít slušivý kabátek v GUI, a pokud to bude umět udělat i nějaký ten graf, bylo by to úplně ideální.
Existuje Ansible Tower, ale tento nástroj je placený, a tak nám do našeho portfolia úplně nezapadá. Naštěstí RedHat uvolnil kódy Ansible Tower pod open-source licencí a dal tak vzniknout projektu AWX, do jehož vývoje je zapojena komunita a ze kterého je následně odvozována placená verze Ansible Tower. Podobně jako tomu je s Fedorou a RHEL.
První milé překvapení mě čekalo hned po prvním přihlášení, když jsem zjistil, jak je AWX rychlé. Odezvy GUI jsou téměř instantní, a to velice přispívá k dobrému dojmu z této aplikace. Co všechno nám tedy AWX přináší navíc oproti čistému Ansible?
Delegace
AWX nám umožňuje vytvářet uživatele a seskupovat je do týmů. Jednotlivým uživatelům nebo týmům pak lze přiřazovat oprávnění k inventáři, přihlašovacím údajům a playbookům. Tyto možnosti nám pak dohromady dávají schopnost jednoduše zpřístupnit automatizační procesy, které můžeme pustit stisknutím jediného tlačítka. Navíc můžeme kontrolovat, kdo a kde může tyto akce pouštět. Téměř v každé infrastruktuře se vyskytuje server, na který raději nikdo nechce sahat. Běží na něm nějaká služba, která je kritická a čas od času se rozhodne přestat fungovat.
Naštěstí stačí tuto službu jen restartovat a všechno zase funguje jak má. Jenže když se služba rozhodne upadnout ve tři hodiny ráno, tak vás moc nepotěší, že kvůli tomu musíte vstávat, když víte, že by tohle hravě zvládl i vrátný. Přesně tohle je situace, kde vám AWX hodně pomůže, můžete totiž našemu „vrátnému“ vytvořit účet, nastavit mu práva jen na tento jeden playbook a naučit ho kliknout na tlačítko, které ho spustí.
Další příklad se nabízí, pokud máte ve firmě vývojáře. Asi se čas od času setkáte s požadavkem na vytvoření nového prostředí. I tady se nabízí využít AWX, vytvořit playbook nastavit práva vývojářům a ukázat jim, jak si snadno a sami mohou toto prostředí vytvořit.
Auditing
Další velkou výhodou při používání AWX oproti čistému Ansible je možnost sledovat, kdo a kdy spustil jaký playbook, na jaké stroje a jak to dopadlo. AWX přidává do Ansible vlastní callback plugin, který zachytává výstup Ansible v reálném čase. Na dashboardu je prezentován přehled, který poskytuje informace o tom, jaké playbooky byly puštěny a jestli se provedly úspěšně nebo ne.
Pokud vidíte, že se běh některého playbooku nepovedl, můžete si ho kliknutím otevřít a podívat se na detaily a problém odstranit. Jak jsem již zmínil, AWX zachytává výstup Ansible a umožňuje nám ve výpisu tasků kliknout na konkrétní task a nechat si v popup okně zobrazit všechna metadata, která jsou spojená s tím taskem, respektive modulem, který se v něm použil. Je to, jako byste si v každém tasku registrovali proměnnou a tu pak vypsali pomocí debug. Všechny tyto informace si AWX ukládá do PostgreSQL.
Rozhraní AWX
V následujících odstavcích se seznámíme s koncepty a názvoslovím používaném v AWX.
Organizace a týmy
AWX nám umožňuje vytvářet lokální účty, ale také se umí napojit na externí zdroje. Mezi nimiž najdete Azure, OAuth2, LDAP, Github, RADIUS, SAML, TACACS+. Nastavení připojení k LDAP serveru, je poměrně přehledné a pro člověka, který už někdy konfiguroval připojení k LDAP, by to nebyl problém zvládnout i bez dokumentace.
Nicméně je dobré se do ní podívat, zejména pokud budete nastavovat různá mapování uživatelů a skupin, což je ostatně věc, kterou určitě budete chtít udělat. Co jsem ještě nezmínil je fakt, že AWX je tzv. multitenantní. To znamená, že nám umožňuje spravovat více organizací v jedné instanci a garantuje nám, že uživatelé jedné organizace uvidí pouze své věci a nedostanou se k datům patřící jiné organizaci.
Ze schématu je patrné, že objekt organizace je v AWX na nejvyšším místě a slouží nám pro logické sloučení úkolů (jobs), týmů, projektů a inventářů. Co tedy jsou úkoly, týmy, projekty a inventáře?
Teams
Na tým bychom mohli v prostředí AWX nahlížet jako na oddělení v organizaci. Stejně jako v reálných organizacích nám slouží k seskupení uživatelů, projektů a práv. Skrze týmy řídíme přístupy (RBAC) a rozdělujeme odpovědnost v prostředí organizace. Vše, co bylo řečeno o nastavování týmu, platí také přímo pro uživatele, pokud si ale v nastavení chceme udržet alespoň trochu pořádek, je lepší vše řešit přes týmy.
Týmů si můžeme v organizaci vytvořit libovolné množství. Jak už bylo řečeno, tým může dostat oprávnění stejně jako uživatel. Stejně tak může dostat oprávnění použít konkrétní credentials. To, že může uživatel nebo tým použít nějaké credentials, neznamená, že je může vidět. To nám dává možnost udělit uživateli nebo týmu přístup, aniž bychom jim prozradili uživatelské jméno a heslo.
Credentials
Jsou místo, kam si můžete uložit všechny možné přístupy a ty pak použít například v momentě kdy AWX pouští Joby na servery, synchronizuje inventáře z externích zdrojů nebo importuje do projektu data z SCM (source code management). Jak už jsem zmínil, přístupy je možné přidělovat uživatelům a týmům, avšak oni ho nemohou vidět. Pokud tedy někomu přidělíte přístup a ten člověk odejde z organizace, nemusíte heslo měnit. Všechna hesla uchovává AWX v šifrované podobě.
Inventories
Inventář je souhrn hostů, na které můžeme pustit úkoly, je to to samé jako v Ansible. To znamená, že můžeme hosty členit do skupin. Informace o hostech a skupinách lze zadat v AWX ručně nebo je naimportovat z jiného zdroje. Ano jedná se vlastně o dynamické inventáře, tak jak je známe z Ansible.
V AWX máme na výběr nejběžnější poskytovatele cloudových služeb, ale můžeme importovat i stávající inventář, který máme hotový z doby, kdy jsme používali Ansible z CLI. Zde bych ještě zmínil, že import z již existujícího projektu je poměrně chytrý a krom samotných hostů se podíval do group_vars a host_vars a naimportoval k daným hostům všechny proměnné. Inventářů můžeme mít i více než jeden.
Projects
Projekt je kolekce playbooků, se kterými můžeme v AWX pracovat. Lze je mít uložené lokálně v adresáři, ale mnohem lepší je mít je v SCM. AWX umí pracovat dnes snad se všemi běžně používanými SCM, jako jsou to Git, Mercurial a Subversion. Pokud už SCM pro správu Ansible playbooků používáte, stačí jen vytvořit projekt a data zpřístupnit v AWX.
Jobs
Job je v podstatě proces, který AWX spouští na pozadí. Je to obvykle instance Job Template. Existují ještě jiné druhy Jobů, jako třeba synchronizace projektů, které spravujeme v SCM. Když to pro naše potřeby zjednodušíme, můžeme říct, že Job je vlastně spuštění playbooku.
Co mi nešlo do hlavy, když jsem poprvé začal pracovat s AWX, bylo, že z nepochopitelných důvodů nazvali něco, čemu Ansible říká playbook, jako Job Template. Říkal jsem si tehdy, pro boha proč? Odpověď na sebe nenechala dlouho čekat a zjistil jsem, že pod názvem Job Template se toho skrývá víc než jen definice playbooku, který se má pustit. I když zjednodušeně by se o tom tak dalo přemýšlet.
Job Template
Takže co to tedy vlastně Job Template je? Job Template je definice playbooku a další množiny parametrů, které jsou potřeba k jeho spuštění. Job Template nám asociuje skrze projekt playbooky, které máme uložené třeba v SCM. Přiřazuje inventory, na kterém se má pustit. Dále credentials, které potřebujeme, abychom se mohli přihlásit například k serveru pomocí SSH. Tohle všechno dohromady nám tedy vytváří Job Template.
Notifications
AWX umožňuje nastavit různé způsoby notifikací. Například přes e-mail, Slack, Twilio, Pagerduty nebo Hipchat. Pokud si nevybereme z nabízených možností, nemusíme ještě zoufat neboť AWX implementuje obecný způsob jakým je webhook. Díky tomu si můžeme například posílat informace do našeho monitorovacího systému. Notifikace můžeme nechat posílat při úspěšném nebo neúspěšném běhu Jobu. Užitečné je nastavit notifikace pro případ neúspěšného běhu a směřovat tyto notifikace na administrátory Job Template, respektive playbooků.
Provision callbacks
Provision callback je mechanismus, který umožňuje použít Ansible v pull módu. Je tedy možné, aby si o spuštění nějakého Job Template řekl daný host, místo toho aby to musel udělat uživatel (nebo scheduler) v AWX. Je nutné si uvědomit, že Job Tempate se pustí pouze na onom stroji, který callback zavolal. Tento mechanismus je zde pro to, aby nám umožnil automatickou konfiguraci strojů, které byly automaticky vytvořeny jiným systémem. Například pomocí AWS auto-scaling, kickstart nebo preseed. Typicky se toto bude spouštět ve skriptu při prvním bootu nebo z cronu.
API
Když byla řeč o Provision callbacks, nelze se nezmínit o API, na kterém je tato funkcionalita postavená. V AWX je vlastně všechno vytvářeno jako API a jak CLI, tak webové rozhraní ho volají. Jinými slovy cokoliv co můžete naklikat ve webovém rozhraní, máte dostupné taky skrze API. Právě díky API můžete playbooky pouštět například z Jobu v Jenkinsu.
Shrnutí
Co tedy AWX přináší na víc oproti Ansible?
- Efektivní způsob práce více lidí (RBAC)
- Přehled o dění (Dashboard, Notifications)
- Bezpečnost (Credentials, Authentication)
- Možnost pull architektury (Provision callbacks)
- Snadná integrace s dalšími nástroji (API)
