Azure od A do… - IaaS v2 a vylepšená správa infrastruktury

Infrastructure as a Service se do Azure dostala před několika lety. Když jsem o ní dělal první screencast někdy v zimě 2012, byla to jednoduchá služba poskytující provoz virtuálních serverů v Azure.
Za tu dobu se podařilo přidat obrovské množství funkcí a jednoduchost zůstala pouze ve správě. Nyní se ještě posouvá a přichází Infrastructure as a Service v2 nebo také VMs pod správou Resource Manageru. V článku se zaměříme na všechny novinky.

Resource Groups

Nejdříve se zaměříme na nejpodstatnější novinku, od které se vše odvíjí a tou jsou Resource Groups. Jedná se o logickou skupinu zdrojů, která seskupuje prostředky pod jednotnou správou. Aby to neznělo tak složitě, zkuste si představit tradiční správu virtuálních serverů. V jedné konzoli spravujete virtuály, ale pokud jich více slouží k provozu jednoho řešení, musíte si to v horším případě pamatovat, v lepším to dohledávat např. podle jmenné konvence, dokumentace atd. Nemusíme ani zacházet do on-premise světa – stejným problémem trpěl i Azure portál.

Obrázek 1 - stávající správa dle zdrojů

Stále ještě produkční portál je organizován přesně podle zmíněného modelu. Po levé straně přepínáte mezi virtuálními servery, storage, sítěmi atd., ale je složitější dohledat vazbu mezi nimi a provádět nějakou akci na všech souvisejících zdrojích je nemožné.
Azure portál vám alespoň umožňuje všechny tyto zdroje najít na jednom místě, ale v případě klasické správy IT je nutné konzolí obsluhovat celou řadu.

Z těchto důvodů přicházejí Resource Groups a seskupují související zdroje od prvního deploymentu. Řekněme, že provozujete řešení, které ke svému provozu potřebuje dva servery za loadbalancerem a vysoce dostupný SQL Server. Je nám tedy jasné, že budeme potřebovat 5 serverů (2x FrontEnd, 2x SQL, 1x File Share Witness pro SQL), storage, kam umístíme všechny servery a síť, která je všechny propojí. Tím naše stavebnice nekončí, protože potřebujeme veřejné IP adresy a loadbalancer. Resource Group dokáže seskupit všechny tyto zdroje, ale zdaleka tím nekončí.

Kromě vizuálně snazšího přehledu Resource Group nabízí hromadné provádění akcí správy. Celou skupinu je možné najednou smazat, což se hodí pro testovací prostředí. Když jste otestovali zamýšlený scénář, smažete vše najednou a bez dohledávání všech závislostí.

Ještě lepší než hromadné mazání je hromadný deployment.

Obrázek 2 - Resource Group

Na celou Resource Group si můžete napsat šablonu, která obsahuje všechny zmíněné zdroje a dokáže je najednou nasadit. Šablony je možné psát v JSONu a v Powershellu.
Editaci JSONu usnadní Visual Studio, které po stažení posledního Azure SDK vše připraví a k dispozici je i JSON Outline Tool, který umožnuje přidání zdrojů (VM, VNET, Storage, WebApp atd.) z grafického rozhraní a zbytek kódu je nutné dopsat.

Obrázek 3 - Editace šablony ve VS a JSON Outline

Dokážete si nyní představit, jak snadné je nasazení více-prvkového řešení, jako je ADFS, SharePoint a další?

Pokud neovládáte práci s Visual Studiem ani PowerShellem, přesto je možné s hromadným deploymentem pracovat. Dostanete-li již napsanou šablonu v JSONu, je možné provést deployment z portálu, pomocí akce Template Deployment, kterou objevíte v Azure Marketplace (samozřejmě to nic nestojí).

Obrázek 4 - Deployment šablony z portálu

Publikace z portálu je i více uživatelsky přívětivější a to zejména ve vyplňování přednastavených možností parametrů.

Co se PowerShellu týče, ResourceManager vyžaduje přepnutí do režimu stejného jména za pomocí cmdletu Switch-AzureMode AzureResourceManager. Správa stávajících zdrojů (v1) je označena jako Azure Service Management. Budoucí verze Azure Powershell modulů budou defaultně přepnuty na Resource Management a pro správu starších v1 zdrojů bude nutné přepnout mód na Service Management. Přepínání modů bude nutné zhruba do podzimu. Do té doby budou k dispozici migrační nástroje v1 > v2 a cmdlety pro v1 budou označeny prefixem ASM (např. Get-AzureASMVM).

Paralelní procesování

Asi největší výhodou nového API a konceptu Resource Managementu je paralelní procesování všech operací. Zaznamenáte jej u drobností jako je hromadné startování a vypínaní virtuálů, ale hlavně u deploymentu. Zdá se to jako samozřejmost, ale mnohé překvapilo, že zdroje typu v1 nebylo možné zapnout nebo vypnout paralelně. Při pokusu o takovou operaci vždy byla výsledem chyba, navíc ne vždy zcela srozumitelná. Pokud jste takovou operaci chtěli provést PowerShellem bylo nutné přistupovat for cyklem ke zvoleným serverům a vypínat je postupně – tedy vždy čekat na vypnutí jednoho a až poté bylo možné přejít k druhému. Jedno takové hromadné vypnutí dvaceti virtuálů jsem zachytil na screenshot níže a můžete vidět, že celá akce trvala něco přes hodinu.

Obrázek 5 - Délka vypnutí dvaceti VM v IaaS V1

Prosté zapnutí a vypnutí je asi první záležitostí, na kterou přijdete a následně ji vyžijete, ale Resource Manager umožňuje využít paralelního zpracování hlavně při deploymentu, kde je tento fakt asi největší výhodou. Vytvoření pětiset virtuálů trvá stejně dlouho, jako deployment jednoho, tedy zhruba 5-10 minut, podle zvolené šablony. V rámci vytváření šablony pro deployment i budoucí správy je možné definovat závislosti a reference – např. VM je závislá na Storage a síťovém adaptéru.

Obrázek 6 - Architektura zdrojů pod Resource Group

Deployment zdrojů ze šablony tedy proběhne dle těchto závislostí a všechny závislé zdroje si nejdříve posoudí, že již byl vytvořen zdroj, na kterém závisí.

Networking

Z hlediska správy sítí nastává několik změn oproti zdrojům typu v1.
Dříve bylo nutné si pamatovat, že Cloud Service s sebou nese veřejnou IP adresu a veřejný DNS záznam. Pokud bylo více serverů v Cloud Service bylo možné využít Availability Set pro zvýšení SLA a Load-Balanced EndPoints pro nastavení průchodu balancovaných portů firewallem na servery.
Nyní dochází k osamostatnění těchto zdrojů a je třeba si o ně explicitně říci. Při vytváření serveru z portálu se nemusíte bát, že byste na něco zapomněli, ale je třeba si to ohlídat při psaní šablon. Není totiž již pravidlem, že virtuální server musí mít veřejnou IP.

Síťová nastavení se nyní vážou na síťový adaptér (NIC), který je v Resource Manageru samostatným stavebním prvkem. Veřejná IP, DNS a Loadbalancery jsou tedy konfigurací adaptéru a až adaptér samotný je připojený k virtuálnímu serveru. Je tak možné si adaptér ponechat, server smazat a následně vytvořit jiný server s existujícím adaptérem a jeho konfigurací.

Oprávnění a přístup

Na úrovni jednotlivých zdrojů i Resource Groups je nyní možné nastavit přístup dle uživatelských rolí – tzv. Role Based Access Control. Můžete tak kontrolovat přístup k jednotlivým částem vámi nasazeného řešení, což je významná změna oproti dosavadnímu řízení práv na úrovni celé subscripce. Dosud bylo možné přidávat co-administrátory a ti měli přístup ke všem zdrojům s plnými právy. Nově je možné udělovat oprávnění na úrovni subscripce, Resource Group a konkrétní zdroj, přičemž probíhá i dědičnost oprávnění v uvedeném pořadí.

Členství uživatelů je možné zvolit z celé řady přednastavených rolí. Bylo by zdlouhavé a zbytečné je zde všechny vypisovat. Kompletní seznam rolí naleznete zde. Základní princip lze dělit do třech úrovní:
Owner je správcem na maximální úrovni. Určuje životní cyklus zdrojů (vytváření, mazání a editace) a také k nim řídí přístup.
Contributor může přispět k životnímu cyklu zdrojů, tedy může vytvářet a spravovat zdroje, ale nemůže je smazat, ani povolit nebo zablokovat přístup dalším uživatelům.
Readermá pouze přístup pro čtení a nemůže vykonávat jakékoliv akce. Tato role se hodí pro audit, účely dokumentace nebo správu billingu.

Logy a audit

V souvislosti s uživateli a jejich rolemi vás jistě napadla otázka, kterak zjistit, kdo provedl tu či onu akci. Již nějakou dobu existuje v Azure Management Service, ale stávající logování bylo ještě vylepšeno.

Obrázek 7 - Audit Logs

Nově je možné procházet všechny operace typu vytvoření, update a smazání a to až do historie devadesáti dnů. Lze tak dohledat i změnu oprávnění a logovány jsou i volání mimo portál, tedy i z PowerShellu, Visual Studia a dalších zdrojů.

Závěr

Azure Resource Manager a IaaS v2 je posunem a usnadněním ve správě virtuálních serverů a souvisejících zdrojů. Díky novému konceptu je možné evidovat závislosti celého řešení pomocí Resource Groups a řídit přístup k jednotlivým zdrojům. O všech akcích se dozvíte v logu a to i v případě volání mimo portál.

Matouš Rokos, MVP, Mainstream Technologies