Governance v Azure: katalog služeb vašeho centrálního IT
Má vaše IT katalog služeb, které nabízíte obchodním jednotkám či jiným týmům? Spravujete pro ně nějakou aplikaci či prostředí? Současně jim ale chcete dát možnost automatického nasazení, aniž by se vás museli ptát? A také zajistit, že náklady na infrastrukturní zdroje půjdou za nimi? Použijte servisní katalog v Azure – vámi navržená a spravovaná řešení, která vaši kolegové najdou jednoduše v portálu k vytvoření.
Proč servisní katalog a proč je jiný, než marketplace
Jako ideální příklad použití pro servisní katalog vidím právě situaci popsanou v úvodu. IT chce nabídnout nějaké standardizované řešení ostatním částem organizace privátním způsobem. Současně se můžete rozhodnout, zda toto řešení bude na straně příjemce startovací šablona a ve vytvořených zdrojích se mohou libovolně hrabat nebo zda preferujete variantu, kdy na vytvořené zdroje mají pouze čtecí práva a vy se jim o ně staráte přestože běží v jejich subscription, do které třeba normálně přístup nemáte.
Druhá situace může být totéž ale s tím, že místo centrálního IT tuto službu nabízí váš dodavatel či partner. Vytvoří pro vás šablonu častěji opakovaného spravovaného řešení a vy sami si ji můžete nasadit a zrušit kolikrát chcete. Stále ovšem jde o privátní situaci, tedy položka katalogu je jen pro vás.
Stejný mechanismus lze použít i v Marketplace. Servisní katalog je privátní záležitost, Marketplace je naopak určen „široké veřejnosti“. Není tedy vhodný pro interní záležitosti, spíše pro aplikační firmy, které chtějí svůj software nabídnout na kliknutí všem zákazníkům Azure (je nutné splnit určité podmínky a být v Microsoft Developer programu).
Co v tom může být a jak to funguje
Samotné zdroje se řeší formou ARM šablony, takže cokoli co lze šablonou definovat, může být součástí této položky v katalogu. Infrastrukturní věci, platformní služby a tak podobně. Může to být jedno VM, celý kompexní cluster VM nebo PaaS infrastruktura s Web App a Azure SQL DB například. Tato ARM šablona je to, co se příjemci vytvoří v jeho subscription, když si to objedná.
Druhou součástkou je definice GUI. Při startu z portálu víte, že všechna řešení mají nějakého průvodce, který se ptá na důležité parametry. Toto GUI máte pod svou kontrolou a můžete se zeptat na co chcete. Posbírané výsledky můžete předat ARM šabloně a tímto jí parametrizovat. V ukázce vám popíšu jak to udělat, aby to měl uživatel co nejjednodušší. Tedy aby si nevybíral složité věci, kterým nemusí rozumět, ale spíše nějaké zjednodušené varianty. Nejčastěji „velikost“ aplikace – Small, Medium, Large. Za touto jednoduchu volbou schováte technické detaily vašeho doporučeného sizingu, třeba velikosti VM, velikosti a typy disků, SKU Azure SQL DB atd. Stejně tak můžete využít kondicionály v ARM a dát možnost jednoduše zvolit, zda chci vysokou dostupnost nebo ne (a podle toho udělám jednu instanci nebo nějaký balancovaný cluster).
Třetí komponentou je nastavení práv. Prvním je nastavení zámečku, tedy zda má mít operátor k vytvořeným zdrojům přístup nebo ne. Pokud to chcete koncipovat jako startovací šablonu (a ať si to pak rozvrtá jak chce), zámeček nedávejte. Pokud to má být vámi spravovaná služba, zámeček dejte a uživateli neříkejte ani administrátorský login do VM či DB. S tím souvisí druhá věc – jste schopni u těchto zdrojů přiřadit práva (RBAC) pro vámi definovaný účet či AAD skupinu. Jinak řečeno centrálnímu IT týmu se automaticky vytvoří práva v roli, kterou definujete, takže může se zdroji patřičně zacházet a starat se o prostředí.
Vyzkoušejme si to
Celou ukázku mám zde: https://github.com/tkubica12/azure-managed-app
Nejprve mrkněte na ARM šablonu s názvem mainTemplate.json. Je to jednoduchá šablonka, která vygeneruje infrastrukturu s jednou VM a veřejným endpointem (výslednou URL mimochodem vrací jako output, který pak uživatel uvidí v portálu). Vaší pozornosti doporučuji jak se implementuje ono zjednodušení sizingu na varianty Small, Medium a Large.
Dále se podívejte na createUiDefinition.json. To je definice GUI, ve které chci odsouhlasení s tím, že to budu spravovat já a následně se ptám na některé parametry, konkrétně velikost řešení a doménové jméno.
Oba soubory zabalíme do zipu a na ten se odkážeme při definici této položky v katalogu.