Plánování prostředí
Vaše aktiva Azure se skládají z mnoha komponent, včetně základní konfigurace, prostředků a nastavení pro celou organizaci a úloh aplikací. Pravděpodobně jste také rozložili aktiva do více prostředí, z nichž každá má jiný účel.
V této lekci se dozvíte o výhodě konzistentního používání kódu pro všechna vaše nasazení a konfiguraci. Pak zvažte úrovně řízení a automatizace, které můžete použít pro každé prostředí. Zvažte také průběh změn v jednotlivých fázích procesu nasazení a ovládací prvky a typy zásad správného řízení, které potřebujete k podpoře zvolené strategie nasazení.
Definování infrastruktury jako kódu
Nasazení a konfigurace Azure pokrývá mnohem více než aplikace, virtuální počítače, služby úložiště a sítě. Například každá z následujících položek je forma konfigurace s odpovídajícími prostředky Azure:
- Uspořádání prostředků vytvořením skupin prostředků, předplatných a skupin pro správu
- Řízení způsobu konfigurace dalších prostředků definováním a použitím definic, iniciativ a přiřazení služby Azure Policy
- Přiřazení rolí, které uživatelům, skupinám a identitám úloh umožní přístup k prostředkům Azure.
- Konfigurace monitorování, včetně upozornění, pro sledování vašich prostředků Azure a zajištění jejich chování podle očekávání
Když poprvé začnete definovat infrastrukturu jako kód, nemusíte vědět o všech položkách, které je možné definovat v šablonách nebo definicích. Jak ale vaše automatizace zralá, je vhodné definovat všechno o vašem prostředí jako kódu. Tímto způsobem můžete pro veškerou konfiguraci Azure použít konzistentní, otestovaný a schválený proces. A protože kód je verze a sledován v úložišti Git, můžete zkontrolovat, jak se vaše prostředí Azure v průběhu času změnilo. Pomocí úložiště Git můžete sledovat historii každé změny.
Předpokládejme například, že potřebujete nakonfigurovat upozornění služby Azure Monitor. Nejprve si můžete myslet, že použití automatizace k nasazení upozornění by nemělo smysl. Upozornění jsou ale důležitou součástí vaší konfigurace Azure. Pokud se upozornění nevytvořilo správně, můžou vám chybět oznámení o kritických produkčních problémech. Definováním výstrah v kódu:
- Členové vašeho týmu můžou zkontrolovat výstrahy a jejich konfiguraci.
- Upozornění můžete nejprve nasadit do neprodukčních prostředí, abyste je mohli otestovat.
- Máte úplnou sledovatelnost změn v konfiguraci Azure.
Prostředí
Když plánujete nasadit infrastrukturu automaticky, je užitečné uvést prostředí, která chcete použít. Mnoho organizací má různé typy prostředí, z nichž každá má různé charakteristiky. Příklad:
- Některá prostředí spouštějí produkční kód, zatímco jiné spouštějí neprodukční verze stejného kódu, třeba s různými konfiguracemi.
- Některá prostředí jsou dlouhodobá a nikdy se nedají odstranit. Ostatní jsou dočasné: vytvoří se automaticky a zničí, když se už nepoužívají.
- Některá prostředí používají váš tým pro vývoj infrastruktury nebo softwaru. Jiní uživatelé používají váš bezpečnostní tým, nebo i váš prodejní tým, když potřebuje předvést produkt potenciálním zákazníkům.
Vezměte v úvahu prostředí, která vaše společnost pro váš web může používat:
Když provedete a potvrdíte změny aplikace nebo infrastruktury, kanál nasadí změny prostřednictvím posloupnosti neprodukčních prostředí: vývoj, testování a příprava. V určitých bodech můžete mít také kroky ručního schvalování, aby definovaní členové týmu mohli ověřit konfiguraci nebo se podívat na protokol kanálu, než bude nasazení pokračovat. Potom kanál nakonec nasadí vaše změny do produkčního prostředí.
Kromě těchto prostředí má váš prodejní tým vlastní ukázkové prostředí, které používá pro komunikaci se zákazníky. Prodejní tým vezme kopii produkčního prostředí a vytvoří jeho ukázkové prostředí. Vaše týmy zabezpečení a testování příležitostně vytvářejí dočasné kopie produkčního prostředí pro penetrační testování a testování výkonnosti.
Váš vývojový tým má také své vlastní sady prostředí. Má sandboxy pro členy vývojového týmu, které můžou používat při zkoumání nových funkcí nebo experimentování se službami Azure. Vývojový tým také vytvoří prostředí kontroly žádostí o přijetí změn pro každou žádost o přijetí změn GitHubu, kterou kontroluje a slučuje.
Řízená prostředí
V některých z těchto prostředí má smysl vyžadovat formální proces pro kontrolu a použití změn. Prostředí tohoto typu se nazývají řízená prostředí. Produkční prostředí by mělo být vždy řízeno. Je vhodné použít také ovládací prvky v některých neprodukčních prostředích. Tímto způsobem můžete zajistit, aby všechna omezení, která ovládací prvky ukládají, byly dobře pochopeny a testovány před produkčním nasazením.
Naproti tomu neovládnutá prostředí nemají mnoho ani žádné formální kontroly. Můžou mít stejný kód a podobnou konfiguraci jako v jiných prostředích, ale umožňují provádět další experimentování a ad hoc změny konfigurace. V nekontrolovatelném prostředí může být uživatelům povoleno měnit konfiguraci pomocí webu Azure Portal nebo přímým spuštěním příkazů Azure CLI nebo Azure PowerShellu. Můžou také vytvářet prostředky bez použití schváleného procesu organizace. Změny provedené v nekontrolovatelných prostředích musí být zachyceny v kódu, aby se mohly začít používat u kontrolovaných prostředí, jako je produkční prostředí.
Poznámka:
Někdy může prostředí ve skutečnosti představovat více fyzických prostředí nebo nasazení. Když například vytváříte dočasné prostředí pro kontroly žádostí o přijetí změn, může být současně aktivní více samostatných prostředí, protože váš tým má otevřeno více žádostí o přijetí změn. Pro účely plánování prostředí je ale můžete považovat za ekvivalentní, protože mají stejné vlastnosti a kontroly.
Po několika diskusích s vaším týmem určíte, která prostředí jsou řízena a nekontrolovatelná. Také se rozhodnete, kdo každé prostředí vlastní.
| Název prostředí | Popis | Vlastník | Životnost | Úroveň řízení |
|---|---|---|---|---|
| Vývoj | Integruje změny z více vývojářů do jednoho prostředí. | Provozní tým | Dlouhodobá životnost | Řízený |
| Test | Prostředí pro spouštění ručních a automatizovaných testů proti změnám. | Provozní tým | Dlouhodobá životnost | Řízený |
| Příprava | Konečné neprodukční prostředí, ve kterém se změny nasazují před produkčním prostředím s konfigurací podobné produkčnímu prostředí. | Provozní tým | Dlouhodobá životnost | Řízený |
| Výroba | Spouští produkční úlohy. | Provozní tým | Dlouhodobá životnost | Řízený |
| Ukázka | Slouží prodejnímu týmu k předvedení produktu novým zákazníkům. | Prodejní tým | Dlouhodobá životnost | Neovládaný |
| Testování výkonu | Dynamicky vytvořené jako duplikát produkčního prostředí pro spouštění testů výkonu a zátěžových testů a po dokončení testů se odstraní. | Testovací tým | Krátká životnost | Neovládaný |
| Testování průniku | Dynamicky vytvořené jako duplikát produkčního prostředí pro spouštění penetračních a bezpečnostních testů a po dokončení testů se odstraní. | Bezpečnostní tým | Krátká životnost | Neovládaný |
| Recenze žádostí o přijetí změn | Dynamicky vytvořené pro každou žádost o přijetí změn, kterou vytvoří člen týmu, aby změnil aplikaci nebo infrastrukturu. Prostředí se odstraní při zavření žádosti o přijetí změn. | Vývojový tým | Krátká životnost | Neovládaný |
| Vývojové sandboxy | Vytvořili členové vývojového týmu experimentování nebo prozkoumání a potom je odstranili, pokud už je nepotřebujete. | Vývojový tým | Krátká životnost | Neovládaný |
Předchozí seznam prostředí je jen příkladem. Ve vaší vlastní organizaci se musíte rozhodnout, která prostředí používáte, jaká by měla být jejich životnost a jakou úroveň řízení každé prostředí potřebuje.
Tip
Při použití těchto procesů v rané fázi nasazení je mnohem jednodušší provádět lint, testovat a kontrolovat kód infrastruktury, a nemusíte je později přidávat a opravovat spoustu poškozeného kódu.
Podobně je mnohem jednodušší pracovat s bezpečnostními prvky, které se nacházejí od začátku a kdy se také použijí v některých neprodukčních prostředích. Díky tomu se váš tým používá k práci v řízeném prostředí.
V rámci studijních programů jsme postupně představili některé z těchto konceptů. Často je vhodné přidat tyto prvky do procesu nasazení co nejdříve.
Izolace jednotlivých prostředí
Je důležité oddělit jednotlivá prostředí a zajistit jejich samostatnou dostupnost všude, kde je to možné. Použití vyhrazených předplatných Azure pro každé prostředí vám může pomoct, ale přesto musíte být opatrní, abyste svá prostředí udržovali oddělená.
Vyhněte se připojení z jednoho prostředí k druhému. Například nepřát partnerský vztah virtuální sítě produkčního prostředí k neprodukční virtuální síti prostředí. Pokud to uděláte, je snadné, aby někdo omylem změnil produkční data z neprodukčního prostředí nebo unikl citlivým produkčním datům do neprodukčního prostředí.
Kontroly a brány
S tím, jak proces nasazení pokračuje, by měl spustit řadu kontrol, které zvýší vaši důvěru v nasazení. Potřebujete určit kontroly, které mají smysl pro každé vaše prostředí, kterými vaše nasazení postupuje.
Mezi kontroly infrastruktury často patří:
- Revize kódu
- Nasazení kódu kontroly do dočasných prostředí a spouštění automatizovaných nebo ručních testů v prostředích.
- Linting.
- Předběžné ověření.
- Ruční testování.
- Ruční schválení.
- Automatizované funkční testování
- Automatizované orientační testování.
- Než přejdete k dalšímu prostředí, čeká se na signály stavu z předchozího prostředí.
Některé z těchto kontrol můžete spustit vícekrát v rámci procesu nasazení, například pro každé řízené prostředí.
Tip
Při návrhu procesu nasazení uveďte všechny kroky, které potřebujete provést, bez ohledu na to, jak malé nebo zřejmé. Buďte tak podrobní, jak můžete. Nemusíte se nejprve rozhodnout automatizovat všechno, ale po provedení tohoto postupu vám pomůže vytvořit podrobný plán pro procesy automatizovaného nasazení v budoucnu.
Brána je automatizovaná nebo ruční kontrola, která musí být úspěšná, aby nasazení pokračovalo.
Ruční zásah
Při kontrole kódu a procesu nasazení je vhodné automatizovat co nejvíce kontrol. Vaše organizace ale může vyžadovat ruční schválení nasazení do produkčního nebo jiného řízeného prostředí.
Pokud pro nasazení používáte ruční schvalovací brány, postupujte podle těchto doporučených postupů:
- Jasně definujte, kdo může schválit nasazení. Pomocí skupin Microsoft Entra definujte schvalovatele místo zadávání jednotlivých uživatelů. Seznam schvalovatelů můžete snadno změnit v budoucnu.
- Pracujte s nasazením tísňového volání. Naplánujte, kdo může nasazení schválit, pokud nejsou k dispozici normální schvalovatelé. K nouzovému nasazení může dojít uprostřed noci nebo během dovolené.
- Omezte lidské zásahy pouze na schválení nebo odmítnutí nasazení. Vyhněte se tomu, aby lidé spouštěli některou z operací nasazení, pokud neexistuje krok, který nemůžete automatizovat.
Řízení
Azure poskytuje nástroje a možnosti, které vám pomůžou řídit vaše prostředí, včetně následujících:
- Azure Policy umožňuje zjišťovat prostředky, které jsou nakonfigurované způsobem, který neodpovídá požadavkům vaší organizace. Může také pomoct zabránit tomu, aby se prostředky vytvářely nebo překonfigurovaly způsobem, který způsobí, že nedodržují předpisy.
- Zamkne se, aby se zabránilo změnám nebo odstranění důležitých prostředků.
- Skupiny pro správu, které vám pomůžou uspořádat předplatná Azure a konzistentně konfigurovat řízení přístupu a zásady na základě rolí napříč vašimi prostředími.
- Azure Monitor umožňuje zaznamenávat metriky a protokoly z vašich prostředků, prezentovat je na řídicích panelech a automaticky vás upozornit, když se odchylují od očekávaných hodnot.
Při vytváření aktiv Azure zvažte použití cílových zón Azure. Pomocí cílové zóny můžete od začátku do svého prostředí začlenit zásady správného řízení. Mnoho cílových zón zahrnuje předem připravené soubory Bicep a Terraform, které vám pomůžou s konfigurací vašeho prostředí. Odkazujeme na další informace v souhrnu.