Sokan beszélnek róla, kevesebben csinálják, a prezentációkban jól mutat, de nem ismerek olyat aki önerőból – itthon – összerakott volna egyetlen futó környezetet is. Gondoltam felkészülök és megpróbálom házon belül kitapasztalni a telepítést és a szükséges beállításokat, addig a fázisig, hogy egy VM-et tudok katalógusból kérni. Szeretném megugrani a harmadik VCP vizsgámat is, ezúttal CMA-ból és jól jön a gyakorlás, bár a gyakorlat általában a VCAP vizsgákon kezdődik, a VCP-knél lexikális tudás kell.
Kezdem mindjárt picivel bentebb, a szükséges vRealize Automation Appliance 7.4 (sajnálatos módon ez még mindig nem lett portolva PhotonOS-re) letöltése és OVA deploy után a következő ablak fogad a konzolon megjelenített URL-en (https://vra.valami.local:5480)
Itt el kell dönteni rögvest, hogy melyik telepítést szeretnénk.
Jelentős a különbség az Enterprise deployment-nél a fentihez képest:
Mindkét esetben szükség van SQL-re, az Enterprise deployment is nemes egyszerűséggel átugorja, pedig valahogy azt is hibatűrővé kell tenni. Always On-t lehet használni, Microsoft SQL Server 2016-tól, szóval itt máris van két géppel több amivel számolni kell, Minimal deployment-nél pedig csak eggyel. Összegezve, első esetben kettő gép lesz (egy maga az appliance, a másik pedig mindenképpen egy Windows hoszt, amin egyben van az IaaS Web és IaaS Manager), a másodikban minden duplikálódik (két appliance, 2 IaaS Web, 2 IaaS Manager). Utóbbi esetben kellhet három Load Balancer is. Tényleg nem kispálya….
Mondanom sem kell, a Minimal-t választottam és azzal kezdtem, hogy felhúztam egy Microsoft Windows Server 2012 R2-t. Ez a gép az, amely tulajdonképpen a munka dandárját végzi, ő felel a feladatok végrehajtásáért, ő beszélget például a vCenter-rel – és sok más egyéb úgynevezett Endpoint-tal. Itt most a két szolgáltatása egy gépen kerül telepítésre, méghozzá igen egyszerű módon. Elegendő letölteni egy apró msi csomagot és azt elindítani.
Fentebb már az látszik, hogy sikeresen települt, miután minden előzetes követelményt is feltett magának (IIS szolgáltatás, JAVA és még sok minden más). Ezek után az SQL elérhetőségének, felhasználójának megadását követően lehetséges felvenni megadni a DEM worker-eket (korábban említettem hogy itt most minden együtt fut majd) ezért itt saját magát adtam meg és egy tartományi felhasználót, aminek adminisztrátor joga van jelen Windows szerveren.
Ezek után szükséges meghatározni az Agent-eket, azaz azokat a komponenseket, amelyek majd az infrastruktúránkkal beszélnek – vCenter, SCVMM stb.
Ezek után még generálni kell pár tanúsíványt és be kell írni a licenszkulcsot, de maga a telepítés igen gyorsan végrehajtódik és hamarosan a konzolon az a képernyő fogad, hogy melyik az az URL, amin keresztül menedzselhető a termék. Esetemben ez a https://vra.valami.local/vcac cím lett. Érdekes, hogy javasolja a telepítő még a végső végrehajtás előtt, hogy minden gépről készítsd egy snapshot-ot, hátha nem jön össze a dolog és akkor legalább az újabb próbálkozáshoz nem kell újra feltelepíteni mindent.
Itt fontos elébe menni a dolgoknak azzal, hogy multi-tenant működésre képes termékről van szó, ezáltal a telepítéskor létrejön egy default tenant, aminek a neve vsphere.local. Ebbe kell belépni a telepítéskor megadott jelszóval és máris az adminisztrációs menüben találjuk magunkat. (Megjegyzés, hogy a VMware az egységes HTML5 UI-t itt még nem érzi fontosnak.)
Itt első dolgunk legyen létrehozni egy lokális felhasználót, a példában vrauser lesz a neve. Kétféle jogot lehet neki adni, az egyik a „Tenant administrator” a másik az „IaaS administrator”.
Állítsuk be a levelezést is, egyelőre én csak a kimenőket állítottam be – lehetséges lenne egyébként például levélben is jóváhagyni kéréseket stb.
Ha ez kész, akkor hozzunk létre egy tenant-ot:
Itt az URL nagyon fontos rész, mivel a tenant-ra specifikus URL így fog végződni, így a fenti esetben „https://vra.valami.local/vcac/org/99999„. A „Local users” tab nem más mint a vsphere.local SSO tartományban lokális felhasználók. Itt hozzunk létre még egy felhasználót, a példában vraadmin lesz. Adjuk meg neki mindkét jogot. Pusztán ezekkel is lehet dolgozni, de a végfelhasználók szempontjából nem barátságos, ha például a tartományi felhasználóik, helyett itt egy másikat kell használni. Egyet azonban mindenképpen létre kell hozni, ezzel fogjuk majd beállítani a tartományi authentikációt.
Ha megvan akkor, ki kell lépni, majd a korábban létrehozott lokális default tenant felhasználóval újra bejelentkezni. Itt kerül beállításra a tartományi authentikáció, az Administration -> Directories menüben.
A következő ablakban a tartományok listájából, ki kell választani azokat amelyeket szeretnénk, illetve azt hogy az AD-ben létező attribútumok, a VMware Identity Manager schema rendszerében melyik mezőnek legyen megfeleltetve. Jó eséllyel össze bírja párosítani őket, de ha nem – lentebb kettő mezőnek nem talál megfelelőt – akkor kézzel kell megadni.
A következő ablakban ki kell választani hogy mely AD csoportokat szeretnénk szinkronizálni az IDM-mel. Elég beírni a tartományt, ami alapján kilistázza az összes csoportot és kézzel lehet válogatni 🙂 A következő oldalon ugyanezt kell megadni a felhasználói entitásokra vonatkozóan. Ha ezekkel végeztünk, akkor máris rendelhetünk jogokat a tartományi csoportoknak, felhasználóknak.
Ha ez kész, akkor hozzunk létre egy vSphere Endpoint-ot. Itt lényegében azt a vCenter-t (vagy többet, ha több endpoint-ot hozunk létre) kell megadni, amelyben a vRA szolgáltatásait akarjuk kialakítani. Azt hiszem az alábbi ablak is árulkodik arról, mennyi mindent képes az Automation használni.
Pár perc kell mire feltérképezi a vCenter-t, hosztokat, datastore-okat stb a rendszer, de ha kész akkor létre kell hozni egy „Fabic Group”-ot, ami lényegét tekintve körülbelül az a klaszter, amibe majd virtuális gépeket akarunk elhelyezni az Automation segítségével.Itt a Fabric Administrator-nál válasszuk ki azt a csoportot/felhasználót, aminek/akinek joga lesz ehhez.
Ezen a ponton át kell lépni a tenant URL-re és belépni az előbb megadott felhasználóval és konfigurálni a valaha létrehozásra kerülő virtuális gépek neveinek formátumát, az Infrastructure -> Administration -> Machine Prefixes menüben. Ez maga lehet globális beállítás is, de a tenant-ra egyedül érvényesülő is.
Ha ez is megvan, akkor már nincs sok hátra az első kérés teljesítéséig, már csak létre kell hozni egy – vagy több csoportot – amit Business Group néven ismer a rendszer. Ezek lehetnek a vállalaton belül csoportok (DevOps, UAT stb) vagy alvállalatok.
Ezek után ezekhez az entitásokhoz „Reservation”-t kell rendelni, azaz olyan erőforrásokat és azok mennyiségét, amennyit használhatnak.
A resources tab-ra váltva ki lehet választani, hogy mennyi memóriát, mely datastore-okon, mennyi területet kívánunk maximálisan kiadni az adott Business Group-nak.
Később még fontos lesz, de a Network fülön ki kell választani, hogy mely port group-okban szeretnénk majd felhasználni a katalógusokban létrehozott erőforrásokat.
Ha ez is kész, akkor ideje kiosztani a szofisztikáltabb jogokat, azaz például ki készíthet Blueprint-et, amolyan terveket, amelyek a katalógusba kerülnek és segítségükkel önkiszolgálóvá válhat a rendszer.
Ha adtunk jogot, akkor ki kell lépni és vissza azzal a felhasználóval, akinek a jogot adtuk. Ekkor láthatóvá válik a Design fül is. Hozzunk létre egy tervet és nevezzük el valahogyan. Egy impozáns szerkesztő jelenik meg, amiben drag and drop módon lehet elhelyezni a komponenseket. Húzzunk rá a kockás felületre egy „vSphere (vCenter) Machine”-t.
A „Build Information” fül a lényeg. A példában egy már létező VM template-et fogok klónozni, ezért itt a következő módon kell beállítani:
A gép méretezését bizonyos határok között azért engedélyezem a kérvényezők számára.
Mentés után egy Service-t hozunk létre, ami nem más mint egy konténer. Meg kell adni ki a birtokosa és ki a támogató csapat ezen szolgáltatáson.
A következő ablakban a Blueprint-ek jelennek meg és kiválasztható, hogy melyeket akarjuk ehhez a szolgáltatáshoz adni.
A „Service”-t pedig „Entitlement”-eken keresztül tudjuk hozzárendelni a felhasználókhoz.
A következő fülön ki kell választani a „Service”-t:
A létrehozott „Blueprint”-eket:
És azokat az akciókat, amiket a felhasználók számára engedélyezett:
Ha idáig eljutottunk, akkor lényegében más nincs, mint kérni egy gépet a katalógusból, bármelyik felhasználó által, hiszen az „Entitlement” fentebb minden felhasználóra engedélyezve lett.
A „Request” gomb megnyomása után lehetőséget ad némi beállítás elvégzésére:
A „Submit” kiválasztása után, máris készül a gép. Felmerül a jogos kérdés, hogy mégis hogyan lehet legalább a port group-ot kiválasztani, amelyikben a gépet szeretnénk. Nos ez nem olyan egyszerű – nem meglepő módon.
Hozzunk létre pár „Property”-t itt Administration -> Property Definitions
Én ezt az ötöt hoztam létre, magukért beszélnek. Az egyetlen amit érdemes kifejteni, az a VLAN / Portgroup.
Ezek után ezeket a Property-ket bele kell tenni egy Property Group-ba:
Ezek után pedig a blueprint-ekben semmi sem akadályozhat meg abban, hogy használjuk őket.
A katalógusból történő kiválasztáskor pedig így néz majd ki:
Azt hiszem érthető, hogy bár nagyszerű dolgok automatizálhatóak a rendszerrel, de azt meg kell szenvedni hogy a katalógus blueprint-jeit kialakítsuk, mivel a felület helyenként nem intuitív, azaz egy blueprint létrehozása nem vezetett semmilyen formában.
