Správa vývojových prostředí aplikací v cílových zónách Azure

Článek
12/13/2023

Tento článek popisuje, jak můžou týmy cloudové platformy implementovat mantinely pro správu aplikačních prostředí v cílových zónách Azure. Vysvětluje také, jak sladit různá vývojová prostředí aplikací s jejich architekturou. Klíčovým aspektem při vytváření správného prostředí je umístění předplatných do příslušných skupin pro správu.

Nastavení základu

Vývojové týmy vyžadují možnost rychle iterovat a týmy zásad správného řízení v cloudu a týmy platforem potřebují spravovat organizační rizika, dodržování předpisů a zabezpečení ve velkém měřítku. Prostředí aplikací můžete správně spravovat tak, že se zaměříte na dva klíčové principy návrhu cílové zóny Azure: zásady správného řízení a demokratizace předplatného. Tyto principy poskytují základní mantinely a popisují, jak delegovat řízení na aplikační týmy. Týmy aplikací používají pokyny k návrhu úloh v architektuře Azure. Nasazují a spravují vlastní prostředky cílové zóny a tým platformy řídí prostředky přiřazením zásad Azure.

Je důležité poskytnout prostředky sandboxu pro částečně řízené prostředky, aby aplikační týmy mohly experimentovat s technologiemi a možnostmi.

Pokud vlastníci aplikací používají správa předplatného nebo jiné procesy vytváření předplatného, musí vědět, jak požádat o předplatná pro více vývojových prostředí.

Tento článek popisuje cílovou zónu Azure, včetně skupin pro správu, zásad a architektury sdílené platformy a cílové zóny úloh nebo aplikací.

Poznámka:

Pokyny v tomto článku jsou určené pouze pro cílové zóny úloh nebo aplikací. Informace o testování a oddělení prostředí pro samotnou platformu cílové zóny Azure najdete v tématu Testovací přístup pro cílové zóny Azure, který popisuje kanárný přístup.

V praxi můžete použít libovolný počet a typ fázovaného prostředí. Tento článek odkazuje na následující fázovaná prostředí.

Environment	Popis	Skupina pro správu
Pískoviště	Prostředí, které se používá pro rychlé inovace prototypů, ale ne pro konfigurace vázané na produkční prostředí	Skupina pro správu sandboxu
Vývoj	Prostředí, které se používá k vytváření potenciálních kandidátů na vydání verze	Skupina pro správu archetypů, jako je corp nebo online
Testování	Prostředí, které se používá k testování, včetně testování částí, akceptace uživatelů a testování kontroly kvality	Skupina pro správu archetypů, jako je corp nebo online
Produkční	Prostředí, které slouží k poskytování hodnoty zákazníkům	Skupina pro správu archetypů, jako je corp nebo online

Další informace najdete v videích, která zpracovávají vývoj, testování a produkční prostředí pro úlohy aplikací a kolik předplatných mám použít v Azure?

Prostředí, předplatná a skupiny pro správu

Jako předpoklad pro tuto část se podívejte do oblasti návrhu organizace prostředků.

Při přijetí postupů cílové zóny Azure je nutné správně uspořádat svá předplatná. V ideálním případě by každé aplikační prostředí mělo mít vlastní předplatné. Tato metoda poskytuje kontroly zabezpečení a zásad, které udržují prostředí izolovaná. Obsahuje potenciální problémy s jedním prostředím.

Samostatná předplatná mají stejné zásady na úrovni archetypu. V případě potřeby můžou vlastníci aplikací přiřadit zásady specifické pro předplatné, které vynucují chování specifické pro aplikace a prostředí.

Některé architektury aplikací vyžadují, aby se služby sdílely mezi prostředími. V takovém případě můžete použít jedno předplatné pro více prostředí. Doporučujeme, aby vlastníci úloh spolupracovali s týmy cloudové platformy a zjistili, jestli je potřeba jedno předplatné pro více prostředí.

Pokud chcete použít jedno předplatné pro více aplikačních prostředí, použijte:

Prostředí se nedají izolovat ve svých vlastních předplatných.
Prostředí mají stejné týmy přiřazené k funkčním rolím, jako jsou síťové operátory.
Prostředí můžou používat stejné zásady.

Pokud musí být úloha aplikace nebo služby v jednom předplatném a potřebujete provést změny zásad, které platí pro každé prostředí, můžete:

Vytvořte novou archetypovou skupinu pro správu pod skupinou pro správu cílových zón. Další informace naleznete v tématu Hierarchie skupin pro správu v tomto článku.
Používejte předplatná sandboxu pro vývojové aktivity. Sandboxy mají méně omezující sadu zásad.
Používejte zásady, které se použijí na úrovni předplatného místo na úrovni skupiny pro správu. Do definic zásad můžete přidat značky, které pomáhají filtrovat a aplikovat zásady na správné prostředí. Zásady můžete také přiřadit nebo vyloučit z konkrétních skupin prostředků.

Zásady můžete přiřazovat během procesu vytváření předplatného jako součást správa předplatného.

U zásad, které implementujete, abyste mohli řídit náklady, použijte definici zásad na úrovni předplatného, pokud je to potřeba. Nebo můžete vlastník cílové zóny zodpovídět za náklady, což poskytuje skutečnou autonomii. Další informace najdete v tématu Automatizace platformy a DevOps.

Upozorňující

Na rozdíl od zásad a ovládacích prvků na úrovni skupiny pro správu můžou zásady a značky na základě předplatného měnit jednotlivci se zvýšenými oprávněními k předplatnému. Správa istrátory s příslušnými rolemi můžou tyto ovládací prvky obejít vyloučením zásad, úpravou zásad nebo změnou značek u prostředků.

V důsledku toho byste neměli používat značky v definicích zásad zaměřených na zabezpečení. Kromě toho nepřiřazujte oprávnění jako vždy aktivní pro následující akce:

Microsoft.Authorization/policyAssignments/*
Microsoft.Authorization/policyDefinitions/*
Microsoft.Authorization/policyExemptions/*
Microsoft.Authorization/policySetDefinitions/*

Tyto akce můžete řídit pomocí privileged Identity Management (PIM).

Hierarchie skupin pro správu

Vyhněte se složitým hierarchií skupin pro správu. Můžou vyžadovat časté změny, neefektivní škálování a nedostatek hodnoty. Aby nedocházelo k těmto potenciálním problémům, jsou skupiny pro správu cílových zón Azure archetypy úloh sladěné. Další informace najdete v tématu Skupina pro správu a organizace předplatného.

Archetypově sladěné znamená, že skupiny pro správu se vytvářejí jenom pro konkrétní archetypy úloh. Například v koncepční architektuře má skupina pro správu cílových zón corp a online podřízené skupiny pro správu. Tyto podřízené skupiny pro správu odpovídají odlišným vzorům archetypů pro úlohy, které uchovávají. Podřízené skupiny pro správu se zaměřují na požadavky na hybridní připojení (VPN/Azure ExpressRoute), jako jsou interní a veřejné aplikace a služby.

Kromě prostředí sandboxu by pro nasazení měly používat různá aplikační prostředí stejný archetyp. I když jsou prostředí rozdělená mezi několik předplatných, nacházejí se ve stejné jedné skupině pro správu (corp nebo online), a to na základě archetypu skupiny pro správu a požadavků.

Předplatná sandboxu můžete použít pro nestrukturovaný vývoj, jako jsou osobní testovací prostředí nebo úlohy, které nemají archetyp. Tým úloh aplikace nebo služby používá skupinu pro správu sandboxu k otestování různých služeb Azure k určení toho, co je pro jejich požadavky nejvhodnější. Jakmile se rozhodnou o službách, můžou pro tým zřídit cílovou zónu (ve správné skupině pro správu s archetypy úloh v hierarchii skupin pro správu cílových zón ).

Prostředí sandboxu je možné použít pro konkrétní aplikace nebo je tým úloh může použít k experimentování.

Další informace naleznete v tématu:

Skupiny pro správu.
Oblast návrhu organizace zdrojů
Přizpůsobte si architekturu cílové zóny Azure tak, aby splňovala požadavky.

Výzvy skupin pro správu na základě prostředí

Skupiny pro správu pro prostředí v rámci archetypů můžou přidávat režijní náklady na správu a poskytovat minimální hodnotu.

Skupina pro správu cílových zón by měla mít univerzální zásady, které vynucují ochranné mantinely pro korp i online podřízené skupiny pro správu. Corp a online mají jedinečné zásady, které vynucují firemní pokyny související s veřejnými a privátními úlohami.

Mnoho organizací vytváří samostatné skupiny pro správu pro životní cyklus vývoje softwaru (SDLC) pro přiřazení zásad a kontrol prostředí. Vpraxich Prostředí SDLC by neměla mít jiné zásady, proto nedoporučujeme samostatné skupiny pro správu.

Vlastníci aplikací můžou změnit topologii nebo konfiguraci prostředků úlohy tak, aby odpovídaly zásadám v několika prostředích SDLC, kterými se propaguje. Tato metoda zvyšuje riziko. Pravidla specifická pro každé prostředí můžou vést ke špatnému vývojovému prostředí pro týmy vývojářů a zajištění kvality. K problémům může dojít také v případě, že aplikace má jednu sadu zásad ochranné mantinely, které fungují v jednom prostředí, a aplikace je vystavena jiné sadě zásad později v cyklu povýšení. Pokud se ovládací prvky změní, budete možná muset aplikaci upravit.

Chcete-li zabránit této nadbytečné práci, vytvořte konzistentní zásady v rámci povýšení kódu v prostředích SDLC. Zásady byste neměli vytvářet pro každé prostředí, ale místo toho poskytovat konzistentní sadu pro všechna vývojová prostředí s výjimkou prostředí sandboxu.

Představte si například, že organizace definuje zásadu, která vyžaduje, aby účty úložiště byly nakonfigurované s konkrétními pravidly brány firewall, aby se zabránilo příchozímu přenosu dat z veřejných sítí. Místo toho účty úložiště používají privátní koncové body v sítích cílových zón Azure pro komunikaci. Pokud vývojové prostředí takové zásady nemá, testování úlohy nenajde chybnou konfiguraci účtu úložiště, který umožňuje veřejný přístup. Testovací nasazení fungují ve vývojovém prostředí a itefikují se. Pokud je řešení povýšeno do jiného prostředí, které má zásady účtu úložiště, nasazení se nezdaří kvůli vynucené zásadě.

V důsledku toho musí vývojový tým aplikací přepracovat své nasazení a architekturu, a to po tom, co už investoval značné úsilí. Tento příklad ukazuje, jak mohou různé zásady v různých prostředích způsobit problémy.

Poznámka:

Následující rovnice ukazuje, proč samostatná skupina pro správu pro každé prostředí nebo úlohy není dobře škálovat: N úloh x Z skupin pro správu = celkové skupiny pro správu.

Pokud má organizace 30 úloh, které každý vyžaduje skupinu pro správu a podřízenou skupinu pro správu pro vývoj, testování a produkční prostředí, zůstane tato organizace v těchto případech:

N = počet úloh/aplikací = 30

Z = počet skupin pro správu pro úlohy a prostředí (1 pro úlohu + 3 pro prostředí) = 4

N (30) x Z (4) = 120 celkového počtu skupin pro správu

Vlastníci aplikací můžou potřebovat zásady, které se budou v různých prostředích uplatňovat jinak. Vlastníci aplikací můžou například vyžadovat konfigurace zálohování pro produkční prostředí, ale ne pro jiná prostředí.

Některé zásady je možné povolit jako zásady auditu na úrovni skupiny pro správu. Aplikační týmy určují, jak implementovat ovládací prvek. Tato metoda nebrání nasazením, ale vytváří povědomí a umožňuje týmům aplikací spravovat jejich jedinečné potřeby. Pak můžou vytvořit zásady podúrovňové úrovně nebo tyto požadavky začlenit do své infrastruktury jako modulů nasazení kódu (IaC).

V tomto modelu sdílené odpovědnosti tým platformy audituje postupy a aplikační tým spravuje implementaci. Tento model může zlepšit flexibilitu nasazení.

Operátoři platformy musí spolupracovat s jednotlivými týmy úloh aplikací nebo služeb (vlastníky cílových zón), aby porozuměli jejich požadavkům. Operátoři platformy můžou poskytovat předplatná na základě požadavků a plánů aplikací. Operátoři platformy se také mohou rozhodnout určit produktové linky pro různé typy úloh, aby mohli vytvářet procesy vytváření předplatného a nástroje na základě běžných požadavků od týmů úloh aplikací nebo služeb.

Scénář: Úlohy založené na virtuálních počítačích

Počáteční úlohy v cílových zónách Azure se často skládají z virtuálních počítačů Azure. Tyto úlohy můžete nasadit v Azure nebo je migrovat z existujících datacenter.

Místo nasazení virtuálních počítačů do více prostředí v jednom předplatném můžete:

Vytvořte předplatná pro každé aplikační prostředí a umístěte je všechny do stejné skupiny pro správu archetypu.
Nasaďte virtuální síť pro každé aplikační prostředí v příslušném předplatném. Velikost virtuální sítě můžete určit na základě velikosti aplikačního prostředí.
Nasaďte virtuální počítače do příslušného předplatného. V případě potřeby můžou virtuální počítače používat různé skladové položky a různé konfigurace dostupnosti pro každé prostředí.

Různé prostředky prostředí aplikací jsou chráněné různými řízeními přístupu. Když vývojáři aplikací nastaví kanály nasazení, může být identita každého kanálu omezená na prostředí. Tato konfigurace pomáhá chránit prostředí před náhodnými nasazeními.

Scénář: služba Aplikace Azure

Úloha s předplatnými prostředí, která používají Službu App Service , může způsobit problémy. Osvědčeným postupem pro vývojáře aplikací je použití slotů nasazení ke správě změn a aktualizací webové aplikace.

Tuto funkci ale můžete použít jenom s aplikací, která je v plánu služby App Service, která může žít jenom v rámci jednoho předplatného. Pokud operátoři platformy vyžadují, aby vlastníci aplikací používali samostatná předplatná pro vývoj, testování a produkční prostředí, může být životní cyklus nasazení aplikace obtížnější spravovat.

V tomto příkladu je nejlepší volbou jedno předplatné pro úlohu aplikace nebo služby. Vlastníci aplikací můžou pro zvýšení zabezpečení používat řízení přístupu na základě role (RBAC) Azure s PIM na úrovni skupiny prostředků.