Governance v Azure: jmenná konvence a tagování

Jste enterprise firma a myslíte to s cloudem vážně? Pak určitě budete chtít dobře řídit governance - kdo co smí, co komu patří, jaké politiky se mají vynutit, jak si rozdělit práci, jak řídit náklady. V tomto seriálu se na to zaměříme.

Dnes se podíváme na téma, které sice není cool, ale důležité je tedy dost... jmennou konvenci a tagování.

Jak na jmennou konvenci a proč

Určitě to znáte. Najdete ve vašem prostředí názvy jako TomikuvServer, knedlik, prvniPokus, dalsi-pokus, nemazat nebo moje_aplikace? Pokud ano, do Azure si to neberte, nepracuje se pak moc dobře :)

Z názvu prostředku v Azure byste měli být schopni dobře poznat o co jde. Ne všechny informace musí (nebo mohou díky omezením na délku) být součástí samotného názvu, ale vyberte ty, co jsou pro vás nejzásadnější. Jaké kategorie můžete typicky zvažovat pro zakomponování do názvu?

  • Typ prostředku, buď nějakou zkratkou s fixní délkou (vm, ip, rg, fw) či s proměnlivou délkou (vm, ip, nsg, disk)
  • Typ prostředí (dev, qa, prod)
  • Organizační jednotka (ať už textem typu finance, marketing nebo kódem)
  • Služba či produkt (crm, billing, eshop)
  • Komponenta či tier (fronend, db, appserver, auth, catalog)
  • Region nasazení (westeu, northeu)
  • Instance (01, 02)
  • Nákladové středisko

Jednotlivé prostředky mají z technických či historických důvodů různá omezení ve tvoření názvů (vezměte v úvahu, že například storage account je tu od roku 2009). Někde velká písmena jdou, někde jdou ale jsou case insensitive, někde nejdou (takže camel case názvy typu jednaDveTri nejsou ideální). Někde můžete použít podtržítko, někde ne (takže jedna_dve nedoporučuji). Ideální je tady najít nejmenšího společného jmenovatele - tím jsou malá písmena a pomlčky. Bohužel existuje jedna výjimka - název storage accountu pomlčky nepodporuje, ale i tak je tahle varianta myslím ideální.

Jak si tedy vybrat co do názvu dávat? Doporučoval bych vybrat jen ty, které jsou nejdůležitější k identifikaci na první pohled - ty ostatní totiž můžete uložit do tagů (viz dále). Tak například nákladové středisko si dám to tagu, organizační jednotku nutně v názvu nepotřebuji, protože třeba pro každou mám samostatnou subskripci. Region nasazení vám třeba nedává smysl, protože chcete pracovat pouze v jednom regionu. Já bych si zvolil například tohle s tím, že pokud nějaké políčko vyloženě nedává smysl, tak ho vynechám (třeba subnet či network jsou každé jiné a nemají víc "instancí", resource group zase nepotřebuje políčko komponenta):

<služba>-<komponenta>-<typ prostredku>-<instance>

Vypadat by to pak mohlo nějak takhle:

V pohledu si je můžeme třeba seskupit podle typu prostředku a stále je to samovysvětlující.

Nebo si vyfiltrovat konkrétní komponentu/tier.

Nastavení jmené konvence je skutečně na vašem zvážení. Tak například typ prostředí (dev, test, prod) do názvu jednotlivých zdrojů dávat nebudeme (to je můj případ), ale můžeme mít specifické názvosloví pro resource group třeba takhle:

<služba>-<prostredi>-<typ prostredku>

Takže moje resource group pak mohou vypadat takhle:

Tagování

Každý zdroj v Azure může mít tagy, což jsou libovolné key:value řetězce. Proč je používat? Typicky je vhodné ke zdrojům přidat nějaká metadata jako je nákladové středisko, typ prostředí (dev, test, prod), kontakt na správce či klasifikace dat (PCI-DSS, confidential, internal, public). Na základě těchto hodnot pak můžeme chtít třeba billingové pohledy (kolik mě stojí všechna test prostředí v organizaci, kolik mám naúčtovat na konkrétní nákladové středisko), řešit provozní situace (koho mám kontaktovat, když tam je chyba) či zjišťovat jak se ke zdrojům chovat z pohledu bezpečnosti.

Můžeme je přidat třeba v portálu na úrovni Resource Group.

Pozor na to, že tagy se nedědí. Při vyúčtování tak můžete nejdřív najít správné resource group a pak koukat na zdroje vevnitř, ale praktičtější (zejména pokud používáte nějakou formu automatizace) je tag dávat ke všem zdrojům.

V GUI si také můžete sloupeček s konkrétním tagem přidat na obrazovku.

Jak vidíte Azure vám umožňuje nasadit dobrou governance nad celým prostředím. Dnes jsme probrali nijak vzrušující, ale důležité téma jmenné konvence a tagování. Udělejte si v Azure pořádek. V příštích dílech se podíváme na další aspekty jako je návrh subscription, virtuální datové centrum či Azure Security Center.



Azure RBAC delegace s omezením - samoobslužnost pro vaše Azure uživatele Governance
Cloud-native Palo Alto firewall jako služba pro Azure Virtual WAN Security
Federované workload identity v AKS - preview bezpečného řešení pro autentizaci služeb bez hesel Security
Azure Firewall Basic - levnější bráška pro malá prostředí nebo distribuované IT Security
Nativní Azure Monitor a Microsoft Sentinel nově umí levnější logy a zabudovanou levnější archivaci - praxe (část 2) Security