Modularizace správy šablon Azure Resource Manageru (šablon ARM) umožňuje snížit opakování, osvědčené postupy modelu při vývoji infrastruktury a mít konzistentní standardní nasazení.
Příkladem použití pro implementaci tohoto typu modularizace je nasazení virtuálních počítačů pomocí metafory velikostí trička. Předpokládejme, že jste nasadili desítky nebo stovky virtuálních počítačů. Tato nasazení používají šablony verze 1.0.0 a mají standardní střední velikost starší řady. Pokud jste jednoduše nasadili nové šablony, může přechod na novou řadu vyžadovat krátký výpadek služby. Když ale sestavíte verzi 1.5.0 a použijete modularizaci, můžete nasadit novou infrastrukturu s aktualizovaným standardem a zachovat starou infrastrukturu v nasaditelném stavu. Díky dostupnosti starých verzí infrastruktury mají týmy produktů a aplikací známou dobrou konfiguraci, na kterou se spoléhají při upgradu na novou verzi, protože mají čas.
Dort vrstev úložišť: Příklad pro podniky
Pokud jde o důvod, proč byste mohli chtít mít silnou předvolbu pro to, kam vaše šablony patří, jak se aktualizují, a tak dále, existují dvě hlavní aspekty: větvení a innersourcing.
Větvení. Tento ukázkový scénář usnadňuje větvení modelů Gitu, které podporují tok Gitflow a tok GitHubu. Další informace o Gitflowu najdete v tématu Použití git-flow k automatizaci pracovního postupu větvení Gitu, blogového příspěvku Od Jeffa Kreeftmeijera. Další informace o toku GitHubu najdete v dokumentaci k toku GitHubu na GitHubu.
Innersourcing. Druhou možností je innersourcing, který přináší postupy spolupráce při vývoji opensourcového softwaru do interního vývoje. V takovém scénáři můžete s jistotou sdílet různé šablony a zdrojový kód modulu, aniž byste se museli starat o oprávnění pro samotné modely nasazení. Další informace o vývoji innersource najdete v tématu Úvod do innersource na GitHubu.
Bicep je deklarativní jazyk pro nasazování prostředků Azure. Opakovaně použitelný kód Bicep může použít Azure Container Registry jako privátní registr pro hostování verzí šablon ARM. Pomocí služby Container Registry tímto způsobem může mít váš podnik proces kontinuální integrace a průběžného doručování (CI/CD) pro infrastrukturu. V rámci procesu CI můžete spouštět integrační testy a testy jednotek a registr kontejneru může po úspěšném sestavení přijímat moduly. Týmy aplikací můžou dál používat starší verze, dokud nebudou připravení upgradovat, nebo můžou aktualizovat, aby využívaly výhod funkcí v novějších verzích šablon.
Kromě tohoto použití služby Container Registry můžete tento model kombinovat s něčím, jako jsou ověřené moduly Azure. Vaše implementace by mohla využívat veřejný registr nebo nejlépe monitorovat veřejná úložiště a načíst změny do privátního registru pro další použití. Načtení změn do vlastního registru kontejneru umožňuje spouštět testy s veřejnými moduly a zároveň zajistit, aby se nepoužívaly v produkčním prostředí, dokud nebudou začleněny postupy pro zvýšení kvality a zabezpečení.
Vrstvy
Model, který je navržen v tomto ukázkovém scénáři, je takový, který se zásobníky. Vrstvy v blízkosti horní části zásobníku mají častější nasazení a nasazení, která jsou vhodnější. Kód Bicep poskytuje konzistentní nasazení. Vývojové týmy, které pracují ve vrstvách pro své příspěvky, vycházejí ze služeb a infrastruktury, které jsou k dispozici v níže uvedených vrstvách. Nic v nižší vrstvě by se nemělo spoléhat na prostředky ve vrstvě nad. Od vrstvy 0 do 3 jsou globální knihovna, globální infrastruktura (globálně sdílené služby), produktová platforma (sdílené služby) a aplikace.
Tento model vytváří autonomii se zarovnáním, což znamená, že:
Běžné nástroje pro usnadnění podniku Například všichni používají Git pro správu zdrojového kódu a všichni používají GitHub Actions pro CI/CD. Ale nepřetěžujeme. Například nemáme mandát, aby všechny týmy používaly Bicep; můžou používat Terraform, šablony ARM a další nástroje.
Možnost sdílet osvědčené postupy. Můžou mít podobu šablon ARM, zlatých obrázků nebo fragmentů kódu. Osvědčenými postupy mohou být také dokumentace konkrétních technik. Například jak otáčet klíče ve vašem prostředí a jak testovat kód.
Některé služby se v zásobníku pohybují směrem dolů. Například tým aplikací může zpočátku vyvíjet šablonu pro nasazení clusteru Kubernetes, který se později načte do produktové platformy jako sdílené služby. Tato šablona se stane tak užitečnou, že se načítá do knihovny ukázek.
Vrstva 0 – globální knihovna
Spodní vrstva je globální knihovna, což je úložiště užitečných tidbitů, které nejsou nasazené do produkčního prostředí. Z hlediska řízení přístupu by měl být přístup pro čtení poskytován komukoli ve společnosti, která ho požaduje. V případě změn, návrhů atd. váš cloud center of Excellence (CCoE) schválí žádosti o přijetí změn a spravuje backlog, jako by to byl jakýkoli jiný produkt.
Vrstva 0 by neměla obsahovat:
- Šablony nasazené v produkčním prostředí
- Tajné kódy nebo konfigurace specifické pro prostředí
Vrstva 0 by měla obsahovat:
- Fragmenty kódu (v Pythonu, C# atd.)
- Ukázky pro Azure Policy
- Šablony ARM, šablony Bicep nebo soubory Terraformu, které se dají použít jako ukázky.
Příkladem je ukázková architektura pro to, jak by vaše společnost napsala nasazení pro třívrstvou aplikaci bez jakýchkoli informací specifických pro prostředí. Tato ukázková architektura může zahrnovat značky, sítě, skupiny zabezpečení sítě atd. Vynechání konkrétních informací pro prostředí je užitečné, protože ne všechno může být nebo musí být vloženo do modulu. Při pokusu o to může dojít k nadměrnému parametrizaci.
Kromě toho by vrstva 0 mohla propojit s dalšími známými dobrými zdroji ukázkového kódu, jako jsou Terraform Registry nebo moduly prostředků Azure). Pokud vaše organizace přijme kód nebo vzor z některého z těchto zdrojů, doporučujeme kód nebo vzor načíst přímo z veřejných zdrojů do vlastní vrstvy 0. Spoléháním na vrstvu 0 můžete psát vlastní testy, úpravy a konfigurace zabezpečení. Tím, že se nespoléháte na veřejné zdroje, snižujete riziko, že se spoléháte na něco, co by mohlo být neočekávaně odstraněno.
Abyste mohli považovat za dobrý vzorový kód, vaše šablony a moduly by měly dodržovat osvědčené postupy vývoje, včetně ověřování vstupu pro zabezpečení a požadavky organizace. Pokud chcete zachovat tuto úroveň rigorií, měli byste do hlavní větve přidat zásady, které budou vyžadovat žádosti o přijetí změn a kontroly kódu pro navrhované změny, které by v případě sloučení měly za následek tok změn do hlavního registru kontejneru.
Vrstva 0 se předá do Azure Pipelines nebo GitHub Actions, aby automaticky vytvářela artefakty s verzí ve službě Azure Container Registry. Můžete vytvořit automatizaci pro zprávy potvrzení Gitu pro implementaci sémantické správy verzí artefaktů. Aby to fungovalo správně, musíte mít deterministický standard pojmenování, například <service.bicep>, aby bylo možné automatizaci udržovat v průběhu času. Pomocí správných zásad větví můžete také přidat integrační testy jako předpoklad pro revize kódu. Můžete to instrumentovat pomocí nástrojů, jako je Pester.
Díky těmto zásadám a ochraně může být registr kontejnerů zdrojem pravdy pro všechny moduly infrastruktury v podniku, které jsou připravené k použití. Měli byste zvážit standardizaci protokolů změn a také indexy dostupných ukázek kódu, aby bylo možné zjistitelnost tohoto kódu. Neznámý kód není k dispozici.
Vrstva 1 – globální infrastruktura: Globálně sdílené služby
Vrstva 1 je úložiště pro konstrukty cílových zón Azure. I když Microsoft dodává šablony pro nasazení cílových zón Azure, budete chtít upravit určité komponenty a zadat soubor parametrů. To je podobné způsobu, jakým načítáte veřejné registry a úložiště modulů do vrstvy 0, jak je popsáno výše.
Klíčovou součástí této architektury je Azure Container Registry. I když vaše společnost nemá v úmyslu používat kontejnery, musíte službu Container Registry nasadit, abyste mohli úspěšně provést správu verzí šablon Bicep. Container Registry umožňuje značné flexibilitě a opakované použití modulů a současně poskytuje zabezpečení a řízení přístupu na podnikové úrovni.
Vrstva 1 by měla obsahovat:
- Přiřazení a definice zásad, které se použijí na úrovni skupiny pro správu nebo předplatného Tyto zásady by se měly shodovat s vašimi firemními požadavky na zásady správného řízení.
- Šablony pro základní síťovou infrastrukturu, jako jsou ExpressRoute, SÍTĚ VPN, virtual WAN a virtuální sítě (sdílené nebo rozbočovač).
- DNS.
- Základní monitorování (Log Analytics).
- Registr podnikového kontejneru
Ochranu větví byste měli nakonfigurovat tak, aby se omezila možnost nasdílení změn do tohoto úložiště. Omezte schvalování žádostí o přijetí změn od jiných vývojářů na členy CCoE nebo zásad správného řízení v cloudu. Přispěvatelé této vrstvy jsou primárně členy skupin, které jsou historicky přidružené ke komponentám v této vrstvě. Například síťový tým sestaví šablony pro síť, provozní tým konfiguruje monitorování atd. Měli byste ale udělit přístup jen pro čtení jednotlivcům, kteří si o to vyžádají, protože chcete povolit vývojářům z jiných skupin navrhovat změny základních infrastruktur. Můžou přispět k vylepšením, ale jejich změny nebude možné sloučit bez schválení a testování.
Tyto soubory by měly využívat moduly v registru kontejneru pro standardní komponenty. Budete ale mít také soubor Bicep nebo řadu souborů Bicep, které jsou přizpůsobené implementaci cílových zón Azure vaší organizace nebo podobné struktuře zásad správného řízení.
Vrstva 2 – produktová platforma: Sdílené služby
Jako sdílené služby pro konkrétní produktovou řadu nebo obchodní jednotku můžete zvážit vrstvu 2, produktovou platformu. Tyto komponenty nejsou univerzální v celé organizaci, ale jsou určené pro konkrétní obchodní potřeby. To by byla vhodná vrstva pro virtuální síť, která je partnerským vztahem s centrem v globální infrastruktuře vrstvy 1. Trezor klíčů je další ukázkovou komponentou pro tuto vrstvu. Trezor klíčů může ukládat sdílené tajné kódy do účtu úložiště nebo databáze, která je sdílená různými aplikacemi v rámci této platformy.
Vrstva 2 by měla obsahovat:
- Přiřazení zásad, která se použijí v předplatném nebo skupině prostředků, aby odpovídala požadavkům na konkrétní produkt.
- Šablony ARM pro trezory klíčů, log analytics, databázi SQL (pokud různé aplikace v rámci produktu používají databázi) a Azure Kubernetes Service.
Měli byste implementovat oprávnění, která omezují možnost nasdílení změn do tohoto úložiště. Stejně jako ostatní vrstvy byste měli použít ochranu větví, abyste měli jistotu, že potenciální zákazník nebo vlastník produktu může schválit žádosti o přijetí změn od jiných vývojářů. Neexistují žádná pevná pravidla pro přístup ke čtení pro produktovou platformu, ale minimálně vývojáři z libovolného aplikačního týmu by měli mít udělený přístup pro čtení, aby mohli navrhovat změny. Vzhledem k tomu, že vrstva 2 může obsahovat určitou proprietární architekturu nebo podobné informace, můžete se rozhodnout omezit přístup na ty v organizaci, které platformu používají. Pokud se ale jedná o tento případ, budete chtít zajistit, abyste vytvořili proces získávání osvědčených postupů a fragmentů kódu z tohoto úložiště, abyste je mohli sdílet s globální knihovnou vrstvy 0.
Vrstva 3 – aplikace
Aplikační vrstva 3 obsahuje komponenty, které jsou postavené na produktové platformě. Tyto komponenty poskytují funkce, které obchodní požadavky. Například pro platformu streamování může jedna aplikace poskytovat funkci vyhledávání, zatímco jiná aplikace poskytuje doporučení.
Vrstva 3 by měla obsahovat:
- Kód aplikace v jazyce C#, Python atd.
- Infrastruktura pro jednotlivé komponenty (to znamená pouze v této aplikaci): funkce, Azure Container Instances, Event Hubs.
Oprávnění jsou omezená pro možnost nasdílení změn do tohoto úložiště. Ochranu větví byste měli použít k tomu, aby člen týmu této aplikace schválil žádost o přijetí změn od jiného člena týmu. Členové týmu by neměli mít povoleno schvalovat vlastní změny. Vzhledem k tomu, že tato vrstva může obsahovat proprietární architekturu, obchodní logiku nebo podobné informace, můžete se rozhodnout omezit přístup na ty v organizaci, kteří tuto aplikaci sestavují. Pokud to ale tak je, měli byste také vytvořit proces získávání osvědčených postupů a fragmentů kódu z této vrstvy, abyste je mohli sdílet s globální knihovnou Vrstva 0.
Běžné aspekty napříč vrstvami
I když tento článek popisuje některé konkrétní podrobnosti pro každou vrstvu, existují také určité vlastnosti pro všechny vrstvy, které byste měli zvážit.
Vaše infrastruktura by měla fungovat, jako by se jedná o aplikaci. To znamená, že byste měli mít proces kontinuální integrace (CI), ve kterém se nové funkce testují plně, s testy jednotek, orientačními testy a integračními testy. Měli byste sloučit pouze kód, který tyto testy projde do větve hlavní verze.
Měli byste také zajistit, abyste měli zavedené zásady větví, abyste jednotlivcům zabránili v obejití procesu, a to i za účelem urychlení. Pokud se proces CI považuje za překážku, znamená to, že jste vytvořili technický dluh, se kterým se musí vypořádat. Neznamená to, že je potřeba odebrat zásady a ochranu.
A konečně, i když možná nemáte index všech úložišť a kód v nich, měla by vaše organizace vyvinout proces, který jednotlivcům umožní požádat o přístup k úložištím. Určitá pravidla by mohla být plně automatizovaná. Můžete například implementovat pravidlo, které uděluje přístup pro čtení bez kontroly přispěvateli, který je v produktovém týmu pro libovolnou aplikaci v daném produktu. Taková pravidla je často možné implementovat pomocí členství na základě skupin a přiřazení rolí založených na skupinách ve vašich prostředích. Konfigurace tohoto typu přístupu by měla pomoct usnadnit vnitřní zdroje a organizační znalosti.
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autoři:
- Tim Sullivan | Vedoucí technický specialista
Další přispěvatelé:
- Gary Moore | Programátor/zapisovač
Další kroky
- Oblast návrhu: Automatizace platforem a DevOps
- Vyspělé týmové struktury
- Co je infrastruktura jako kód?
- Azure/ResourceModules: Toto úložiště zahrnuje platformu CI pro vyspělé a kurátorované moduly Bicep. Platforma podporuje Azure Resource Manager i Bicep a jeho funkce můžete používat s akcemi GitHubu a Azure Pipelines.
- Vytvoření privátního registru pro modul Bicep