Tato referenční architektura poskytuje pokyny k nasazení klíčové úlohy, která používá centralizované sdílené služby, potřebuje místní připojení a integruje se s jinými úlohami podniku. Tento návod je určený pro vlastníka úlohy, který je součástí aplikačního týmu v organizaci.
V této situaci se můžete dozvědět, když vaše organizace chce nasadit úlohu v cílové zóně aplikace Azure, která dědí skupinu pro správu Corp. Očekává se, že se úloha integruje s předem zřízenými sdílenými prostředky v cílové zóně platformy Azure, kterou spravují centralizované týmy.
Důležité
Co je cílová zóna Azure? Cílová zóna aplikace je předplatné Azure, ve kterém se úloha spouští. Je připojený ke sdíleným prostředkům organizace. Prostřednictvím tohoto připojení má přístup k základní infrastruktuře potřebné ke spuštění úlohy, jako jsou sítě, správa přístupu k identitám, zásady a monitorování. Cílové zóny platformy jsou kolekce různých předplatných, z nichž každá má určitou funkci. Například předplatné Připojení ivity poskytuje centralizované překlady DNS, místní připojení a síťová virtuální zařízení, která jsou k dispozici pro použití aplikačními týmy.
Jako vlastník úlohy získáte výhodu tím, že přesměrujete správu sdílených prostředků do centrálních týmů a zaměříte se na vývoj úloh. Organizace přináší výhody díky uplatňování konzistentních zásad správného řízení a amortizace nákladů napříč několika úlohami.
Důrazně doporučujeme porozumět konceptu cílových zón Azure.
V tomto přístupu je maximální spolehlivost sdílenou odpovědností mezi vámi a týmem platformy. Centrálně spravované komponenty musí být vysoce spolehlivé pro klíčové úlohy, aby fungovaly podle očekávání. Musíte mít důvěryhodný vztah s týmem platformy, aby se problémy s nedostupností v centralizovaných službách, které ovlivňují zatížení, zmírňovaly na úrovni platformy. Váš tým je ale zodpovědný za řízení požadavků s týmem platformy, aby dosáhl vašich cílů.
Tato architektura staví na klíčové základní architektuře se síťovými ovládacími prvky. Než budete pokračovat v tomto článku, doporučujeme se seznámit se základní architekturou .
Poznámka:
Pokyny jsou podporovány ukázkovou implementací na produkční úrovni, která představuje důležitý vývoj aplikací v Azure. Tuto implementaci můžete použít jako základ pro další vývoj řešení jako první krok k produkčnímu prostředí.
Klíčové strategie návrhu
Použijte tyto strategie na základě klíčového směrného plánu:
Kritická cesta
Ne všechny komponenty architektury musí být stejně spolehlivé. Kritická cesta zahrnuje komponenty, které musí být funkční, aby úloha neměla žádné výpadky nebo snížený výkon. Udržování této cesty při štíhlé cestě minimalizuje body selhání.
Životní cyklus komponent
Zvažte životní cyklus kritických komponent, protože má vliv na cíl dosažení téměř nulového času. Komponenty mohou být dočasné nebo krátkodobé prostředky, které lze vytvořit a podle potřeby zničit; dočasné nebo dlouhodobé prostředky, které sdílejí životnost se systémem nebo oblastí.
Externí závislosti
Minimalizujte externí závislosti na komponentách a procesech, které můžou zavádět body selhání. Architektura má prostředky vlastněné různými týmy mimo váš tým. Tyto komponenty (pokud jsou kritické) jsou v oboru pro tuto architekturu.
Topologie předplatného
Cílové zóny Azure neznamenají jednu topologii předplatného. Naplánujte své nároky na předplatné předem s týmem platformy tak, aby vyhovoval požadavkům na spolehlivost úloh ve všech prostředích.
Autonomní pozorovatelnost do kritické cesty
Provádějte vyhrazené monitorovací prostředky, které týmu umožňují rychle dotazovat shromažďování dat (zejména kritickou cestu) a reagovat na nápravy.
Architektura
Stáhněte si soubor aplikace Visio s touto architekturou.
Komponenty této architektury jsou stejné jako kritická základní architektura se síťovými ovládacími prvky. Popisy jsou stručné. Pokud potřebujete další informace, podívejte se na odkazované články. Dokumentaci k produktům o službách Azure najdete v tématu Související prostředky.
Globální prostředky
Tyto prostředky se nachází v předplatných cílových zón aplikace. Globální prostředky nejsou dočasné a sdílejí životnost systému. Služby Azure a jejich konfigurace zůstávají stejné jako základní globální prostředky.
Místní síťové prostředky
Tyto prostředky jsou živé napříč předplatnými cílové zóny platformy a předplatnými cílových zón aplikace. Základní architektura nasadí všechny prostředky vlastněné vámi. V této architektuře se síťové prostředky poskytují prostřednictvím předplatného Připojení ivity, které jsou součástí cílové zóny platformy.
V tomto článku se podívejte do části Místní centrální virtuální síť .
Zdroje místního razítka
Tyto prostředky se nachází v předplatných cílových zón aplikace. Tyto prostředky nesdílejí nic s jinými prostředky s výjimkou globálních prostředků.
Většina služeb Azure a jejich konfigurace zůstává stejná jako architektura základního razítka s výjimkou síťových prostředků, které předem zřídí tým platformy.
V tomto článku se podívejte na část Virtuální síť s regionální paprskovou sítí .
Externí zdroje
Úloha komunikuje s místními prostředky. Některé z nich jsou na kritické cestě pro úlohu, například místní databáze. Tyto prostředky a komunikace s nimi jsou začleněny do celkové složené smlouvy o úrovni služeb (SLA) úlohy. Veškerá komunikace probíhá prostřednictvím předplatného Připojení ivity. Existují další externí prostředky, které můžou úlohy dosáhnout, ale nejsou považovány za kritické.
Prostředky kanálu nasazení
Kanály sestavení a verze pro kritickou aplikaci musí být plně automatizované, aby se zajistil konzistentní způsob nasazení ověřeného razítka. Tyto prostředky zůstávají stejné jako kanál nasazení podle směrného plánu.
Regionální monitorovací zdroje
Tyto prostředky se nachází v předplatných cílových zón aplikace. Data monitorování globálních prostředků a regionálních prostředků se ukládají nezávisle na sobě. Služby Azure a jejich konfigurace zůstávají stejné jako základní monitorovací prostředky.
V tomto článku se podívejte na část Aspekty monitorování.
Prostředky pro správu
K získání přístupu k privátnímu výpočetnímu clusteru a dalším prostředkům tato architektura používá agenty privátního sestavení a instance virtuálních počítačů jump box. Azure Bastion poskytuje zabezpečený přístup ke jump boxům. Prostředky uvnitř razítek zůstanou stejné jako základní prostředky pro správu.
Aspekty sítí
V tomto návrhu se úloha nasadí do cílové zóny aplikace a potřebuje připojení k federovaným prostředkům v cílové zóně platformy. Účelem může být přístup k místním prostředkům, řízení výchozího provozu atd.
Topologie sítě
Tým platformy rozhoduje o síťové topologii pro celou organizaci. V této architektuře se předpokládá hvězdicová topologie . Alternativou může být Azure Virtual WAN.
Virtuální síť regionálního centra
Předplatné Připojení ivity obsahuje centrální virtuální síť s prostředky, které sdílí celá organizace. Tyto prostředky vlastní a spravují tým platformy.
Z hlediska klíčového cíle je tato síť mimo dočasný a tyto prostředky jsou na kritické cestě.
| Prostředek Azure | Účel |
|---|---|
| Azure ExpressRoute | Poskytuje privátní připojení z místního prostředí k infrastruktuře Azure. |
| Azure Firewall | Funguje jako síťové virtuální zařízení, které kontroluje a omezuje odchozí provoz. |
| Azure DNS | Poskytuje překlad názvů mezi místními místy. |
| VPN Gateway | Připojení vzdálená organizace pobočky přes veřejný internet do infrastruktury Azure. Funguje také jako alternativa připojení k zálohování pro zvýšení odolnosti. |
Prostředky se zřídí v každé oblasti a partnerské vztahy s paprskovou virtuální sítí (popsané dále). Ujistěte se, že rozumíte aktualizacím síťových virtuálních zařízení, pravidel brány firewall, pravidel směrování, převzetí služeb při selhání ExpressRoute službě VPN Gateway, infrastruktuře DNS atd.
Poznámka:
Klíčovou výhodou při používání federovaného centra je, že úloha se může integrovat s jinými úlohami v Azure nebo mezi místy procházením síťových center spravovaných organizací. Tato změna také snižuje provozní náklady, protože část odpovědnosti se přesouvá do týmu platformy.
Virtuální síť s regionálními paprsky
Cílová zóna aplikace má alespoň dvě předem zřízené virtuální sítě Azure pro každou oblast, na kterou odkazují místní razítka. Tyto sítě nejsou dočasné. Jeden obsluhuje produkční provoz a druhý cílí na nasazení vNext. Tento přístup umožňuje provádět spolehlivé a bezpečné postupy nasazení.
Provozní virtuální síť
Provozní provoz je izolovaný v samostatné virtuální síti. Tato virtuální síť není dočasný a vlastníte tuto síť. Tato architektura udržuje stejný návrh jako základní architektura se síťovými ovládacími prvky.
Mezi provozní sítí a paprskovou sítí neexistuje žádný partnerský vztah. Veškerá komunikace probíhá prostřednictvím privátních propojení.
Sdílená odpovědnost
Jasně pochopit, který tým je zodpovědný za každý prvek návrhu architektury. Tady jsou některé klíčové oblasti.
Plánování IP adres
Po odhadu velikosti potřebné ke spuštění úlohy spolupracujte s týmem platformy, aby mohl síť správně zřídit.
Tým platformy
Zadejte jedinečné adresy pro virtuální sítě, které se účastní partnerských vztahů. Překrývající se adresy, například místní sítě a sítě úloh, můžou způsobit přerušení, které vede k výpadku.
Přidělte adresní prostory IP adres, které jsou dostatečně velké, aby obsahovaly prostředky modulu runtime a nasazení, zpracovávaly převzetí služeb při selhání a podporovaly škálovatelnost.
Předem zřízená virtuální síť a partnerské vztahy musí být schopné podporovat očekávaný růst úlohy. Tento růst musíte pravidelně vyhodnocovat s týmem platformy. Další informace najdete v tématu Připojení ivity do Azure.
Podsítě sítě s regionálními paprsky
Zodpovídáte za přidělování podsítí v regionální virtuální síti. Podsítě a prostředky v nich jsou dočasné. Adresní prostor by měl být dostatečně velký, aby vyhovoval potenciálnímu růstu.
Podsíť privátních koncových bodů Po dosažení provozu do virtuální sítě je komunikace se službami PaaS v síti omezená pomocí privátních koncových bodů, stejně jako základní architektura se síťovými ovládacími prvky. Tyto koncové body se umístí do vyhrazené podsítě. Privátní IP adresy k privátním koncovým bodům se přiřazují z této podsítě.
Podsíť clusteru Požadavky na škálovatelnost úlohy ovlivňují, kolik adresního prostoru má být přiděleno pro podsítě. Při horizontálním navýšení kapacity uzlů a podů AKS se IP adresy přiřazují z této podsítě.
segmenty sítě.
Udržujte správnou segmentaci tak, aby spolehlivost vaší úlohy nebyla ohrožena neoprávněným přístupem.
Tato architektura používá skupiny zabezpečení sítě (NSG) k omezení provozu napříč podsítěmi a předplatným Připojení ivity. Skupiny zabezpečení sítě používají značky ServiceTag pro podporované služby.
Tým platformy
Vynucujte použití skupin zabezpečení sítě prostřednictvím zásad Azure Network Manageru.
Mějte na paměti návrh úloh. Mezi kolky neexistuje žádný přímý provoz. Nejsou tam také toky mezi oblastmi. Pokud jsou tyto cesty potřeba, provoz musí protékat přes předplatné Připojení ivity.
Zabraňte zbytečnému provozu rozbočovače pocházejícího z jiných úloh do klíčové úlohy.
Odchozí provoz z regionálních kolků
Veškerý odchozí provoz z každé regionální paprskové sítě se směruje přes centralizovanou bránu Azure Firewall v místní centrální síti. Funguje jako další segment směrování, který kontroluje a pak povoluje nebo zakazuje provoz.
Tým platformy
Vytvořte trasy definované uživatelem pro danou vlastní trasu.
Přiřaďte zásady Azure, které zablokují tým aplikací vytváření podsítí, které nemají novou směrovací tabulku.
Poskytněte týmu aplikací odpovídající oprávnění řízení přístupu na základě role (RBAC), aby mohly rozšířit trasy na základě požadavků úlohy.
Redundance ve více oblastech
Vaše klíčové úlohy musí být nasazené ve více oblastech, aby bylo možné odolat oblastním výpadkům. Spolupracujte s týmem platformy a ujistěte se, že je infrastruktura spolehlivá.
Tým platformy
Nasaďte centralizované síťové prostředky v jednotlivých oblastech. Klíčové metodologie návrhu vyžaduje regionální izolaci.
Ve spolupráci s aplikačním týmem můžete odhalit skryté regionální závislosti, aby degradovaný prostředek platformy v jedné oblasti neměl vliv na úlohy v jiné oblasti.
Překlad DNS
Předplatné Připojení ivity poskytuje privátní zóny DNS. Tento centralizovaný přístup ale nemusí stačit k potřebám DNS, které můžou být specifické pro váš případ použití. Zřízení vlastních zón DNS a propojení s místním razítkem Pokud aplikační tým nevlastní DNS, bude správa privátních propojení pro globální prostředky, jako je Azure Cosmos DB, náročná.
Tým platformy
Delegujte zóny Azure Privátní DNS týmu aplikace tak, aby pokrývala jejich případy použití.
V případě místní centrální sítě nastavte hodnotu serverů DNS na Výchozí (poskytované Azure) pro podporu privátních zón DNS spravovaných týmem aplikací.
Aspekty návrhu prostředí
Obecně se doporučuje umístit úlohy do samostatných prostředí pro produkční, předprodukční a vývoj. Tady je několik klíčových aspektů.
Jak se udržuje izolace?
Produkční prostředí musí být izolované od jiných prostředí. Nižší prostředí by také měla udržovat úroveň izolace. Vyhněte se sdílení prostředků vlastněných aplikací mezi prostředími.
Pro globální, regionální a kolkovací prostředky vlastněné týmem aplikací se vyžaduje jedno produkční prostředí. Předprodukční prostředí, jako je příprava a integrace, jsou potřeba k zajištění testování aplikace v prostředí, které simuluje produkční prostředí co nejvíce. Vývojové prostředí by mělo být vertikálně snížit kapacitu produkční verze.
Jaký je očekávaný životní cyklus?
Předprodukční prostředí je možné po dokončení ověřovacích testů zničit. Doporučuje se, aby vývojová prostředí sdílela životnost funkce a po dokončení vývoje se zničila. Tyto akce prováděné automatizací kontinuální integrace nebo průběžného nasazování (CI/CD).
Jaké jsou kompromisy?
Zvažte kompromisy mezi izolací prostředí, složitostí správy a optimalizací nákladů.
Tip
Všechna prostředí by měla mít závislosti na produkčních instancích externích prostředků, včetně prostředků platformy. Například produkční regionální centrum v předplatném Připojení ivity. Budete moct minimalizovat rozdíl mezi předprodukčním a produkčním prostředím.
Topologie předplatného pro infrastrukturu úloh
Předplatná vám udělí tým platformy. V závislosti na počtu prostředí budete požadovat několik předplatných jenom pro jednu úlohu. V závislosti na typu prostředí můžou některá prostředí potřebovat vyhrazená předplatná, zatímco jiná prostředí se můžou konsolidovat do jednoho předplatného.
Bez ohledu na to, že s týmem platformy navrhnete topologii, která splňuje celkový cíl spolehlivosti pro danou úlohu. Sdílení prostředků poskytovaných platformou mezi prostředími ve stejném předplatném je výhodné, protože bude odrážet produkční prostředí.
Poznámka:
Použití více předplatných k zahrnutí prostředí může dosáhnout požadované úrovně izolace. Předplatná cílové zóny se dědí ze stejné skupiny pro správu. Konzistence s produkčním prostředím je tedy zajištěna pro testování a ověřování.
Produkční předplatné
U předplatného může existovat omezení prostředků. Pokud všechny tyto prostředky přidělíte v jednom předplatném, můžete tyto limity dosáhnout. Na základě jednotek škálování a očekávaného škálování zvažte distribuovaný model. Příklad:
Jedno předplatné, které obsahuje agenty sestavení Azure DevOps i globální prostředky.
Jedno předplatné pro každou oblast Obsahuje regionální zdroje, razítkové zdroje a jump boxy pro regionální razítka.
Tady je příklad topologie předplatného použitá v této architektuře.
Předprodukční předplatné
Vyžaduje se aspoň jedno předplatné. Může spouštět mnoho nezávislých prostředí, ale doporučuje se mít více prostředí ve vyhrazených předplatných. Toto předplatné může také podléhat omezením prostředků, jako je produkční předplatné popsané výše.
Vývojové předplatné
Vyžaduje se aspoň jedno předplatné. Toto předplatné může podléhat omezením prostředků, pokud spustí všechna nezávislá prostředí. Můžete si tedy vyžádat více předplatných. Doporučujeme mít jednotlivá prostředí ve svých vyhrazených předplatných.
Snažte se co nejvíce spárovat produkční topologii.
Aspekty nasazení
Selhání nasazení nebo chybné verze jsou běžnými příčinami výpadků aplikací. Důkladně otestujte aplikaci (a nové funkce) v rámci životního cyklu aplikace. Při nasazování úlohy do cílové zóny budete muset integrovat návrh s prostředky poskytovanými platformou a zásadami správného řízení.
Přečtěte si: Dobře navržená kritická úlohy: Nasazení a testování.
Infrastruktura nasazení
Spolehlivost infrastruktury nasazení, jako jsou agenti sestavení a jejich síť, je často stejně důležitá jako prostředky modulu runtime úlohy.
Tato architektura používá agenty privátního sestavení k zabránění neoprávněnému přístupu, který může mít vliv na dostupnost aplikace.
Zajištění izolace mezi prostředky nasazení se důrazně doporučuje. Infrastruktura nasazení by měla být vázaná na vaše předplatná úloh pro dané prostředí. Pokud používáte více prostředí v předprodukčních předplatných, vytvořte další oddělení omezením přístupu jenom na jednotlivá prostředí. Prostředky nasazení pro každou oblast je možné zvážit, aby byla infrastruktura nasazení spolehlivější.
Nasazení nulového výpadku
Aktualizace aplikace může způsobit výpadky. Vynucování konzistentních nasazení zvýší spolehlivost. Tyto přístupy se doporučují:
- Máte plně automatizované kanály nasazení.
- Nasaďte aktualizace v předprodukčním prostředí na čisté razítko.
Další informace najdete v tématu Klíčové pokyny k nasazení a testování.
V základní architektuře se tyto strategie implementují zrušením zřízení a následným odstraněním razítka s každou aktualizací. V tomto návrhu není možné dokončit zřízení, protože tým platformy vlastní některé prostředky. Model nasazení se tedy změnil.
Model nasazení
Základní architektura používá k nasazení aktualizací aplikací model Blue-Green. Nové razítka se změnami se nasadí spolu s existujícími razítky. Po přesunutí provozu na nové razítko se stávající razítko zničí.
V tomto případě je daná partnerský virtuální síť mimo dočasný. Kolek nesmí vytvořit virtuální síť ani partnerský vztah k regionálnímu centru. Tyto prostředky budete muset v každém nasazení znovu použít.
Kanárový model může dosáhnout bezpečného nasazení s možností vrácení zpět. Nejprve se nasadí nové razítko se změnami kódu. Kanál nasazení odkazuje na předem zřízenou virtuální síť a přiděluje podsítě, nasazuje prostředky a přidává privátní koncové body. Pak přesune provoz do těchto podsítí v této předem zřízené virtuální síti.
Pokud už existující kolek nepotřebujete, kanál odstraní všechny prostředky kolku s výjimkou prostředků vlastněných platformou. Virtuální síť, nastavení diagnostiky, partnerský vztah, adresní prostor IP adres, konfigurace DNS a řízení přístupu na základě role (RBAC) se zachovají. V tomto okamžiku je razítko v čistém stavu a připraveno k dalšímu novému nasazení.
Zásady Azure DINE (deploy-if-not-exists)
Cílové zóny aplikací Azure můžou mít zásady Azure DINE (deploy-if-not-exists). Tyto kontroly zajišťují, aby nasazené prostředky splňovaly firemní standardy v cílových zónách aplikace, i když jsou vlastníkem aplikačního týmu. Mezi nasazením a konečnou konfigurací prostředků může docházet k neshodě.
Seznamte se s dopadem všech zásad DINE, které se použijí na vaše prostředky. Pokud dojde ke změnám konfigurace prostředků, začlente záměr zásad do deklarativních nasazení v rané fázi vývojového cyklu úlohy. Jinak může dojít k posunu, který vede k rozdílu mezi požadovaným stavem a nasazeným stavem.
Správa přístupu k předplatnému nasazení
Zacházejte s hranicemi předplatného jako s hranicemi zabezpečení, abyste omezili poloměr výbuchu. Hrozby můžou ovlivnit spolehlivost úlohy.
Tým platformy
- Udělte týmům aplikací autorizaci pro operace s oprávněními vymezenými pro předplatné cílové zóny aplikace.
Pokud spouštíte více nasazení v rámci jednoho předplatného, porušení zabezpečení ovlivní obě nasazení. Doporučuje se spouštění nasazení ve vyhrazených předplatných. Vytvořte instanční objekty na prostředí pro zachování logického oddělení.
Instanční objekt by měl poskytovat autonomii nad prostředky úloh. Měla by také mít omezení, která zabrání nadměrné manipulaci s prostředky platformy v rámci předplatného.
Důležité informace o monitorování
Platforma cílové zóny Azure poskytuje sdílené pozorovatelné prostředky jako součást předplatných pro správu. Centralizovaný provozní tým podporuje aplikační týmy, aby používaly federovaný model. V případě kritických úloh se ale nedoporučuje jedno centralizované úložiště pozorovatelnosti, protože může být kritickým bodem selhání. Důležité úlohy také generují telemetrii, která nemusí být použitelná nebo použitelná pro centralizované provozní týmy.
Proto se důrazně doporučuje autonomní přístup k monitorování. Operátory úloh jsou nakonec zodpovědné za monitorování a musí mít přístup ke všem datům, která představují celkový stav.
Základní architektura se řídí tímto přístupem a pokračuje v této referenční architektuře. Azure Log Analytics a Aplikace Azure Přehledy se nasazují regionálně a globálně za účelem monitorování prostředků v těchto oborech. Agregace protokolů, vytváření řídicích panelů a upozorňování je určená pro váš tým. Využijte výhod funkcí diagnostiky Azure, které odesílají metriky a protokoly do různých jímek a podporují požadavky platformy pro shromažďování metrik a protokolů.
Model stavu
Klíčové metodologie návrhu vyžaduje model stavu systému. Když definujete celkové skóre stavu, zahrňte toky cílové zóny platformy v oboru, na kterých aplikace závisí. Vytváření dotazů na protokoly, stav a výstrahy za účelem monitorování napříč pracovními prostory
Tým platformy
Udělte dotaz na řízení přístupu na základě role (RBAC) a jímky protokolu čtení pro relevantní prostředky platformy, které se používají v kritické cestě klíčové aplikace.
Podpora organizačního cíle spolehlivosti směrem k klíčové úloze tím, že týmu aplikace poskytne dostatek oprávnění k provádění operací.
V této architektuře model stavu zahrnuje protokoly a metriky z prostředků zřízených v předplatném Připojení ivity. Pokud tento návrh rozšíříte tak, aby se dostal k místnímu prostředku, jako je databáze, musí model stavu zahrnovat síťové připojení k tomuto prostředku, včetně hranic zabezpečení, jako jsou síťová virtuální zařízení v Azure a místní prostředí. Tyto informace jsou důležité k rychlému určení původní příčiny a nápravě dopadu na spolehlivost. Došlo například k chybě při pokusu o směrování do databáze nebo došlo k problému s databází?
Přečtěte si: Dobře navržená kritická úlohy: Modelování stavu.
Integrace se zásadami a pravidly poskytovanými platformou
Předplatné cílové zóny aplikace dědí zásady Azure, pravidla Azure Network Manageru a další ovládací prvky ze své skupiny pro správu. Tým platformy tyto mantinely poskytuje.
Pro nasazení nezávisí výhradně na zásadách poskytovaných platformou, protože:
- Nejsou navrženy tak, aby pokryly potřeby jednotlivých úloh.
- Zásady a pravidla se můžou aktualizovat nebo odebrat mimo váš tým, takže to může mít vliv na spolehlivost.
Důrazně doporučujeme vytvářet a přiřazovat zásady Azure v rámci nasazení. Toto úsilí může vést k nějaké duplicitě, ale to je přijatelné vzhledem k možnému dopadu na spolehlivost systému. Pokud v zásadách platformy dojde ke změnám, zásady úloh budou platit i místně.
Tým platformy
- Při vývoji zásad zapojte aplikační tým do procesu správy změn.
- Mějte na paměti zásady používané týmem aplikací. Vyhodnoťte, jestli se mají přidat do skupiny pro správu.
Nasazení této architektury
Aspekty sítí této architektury se implementují v klíčové Připojení implementaci.
Poznámka:
Implementace Připojení je určená k ilustraci klíčové úlohy, která závisí na organizačních prostředcích, integruje se s jinými úlohami a používá sdílené služby. Implementace předpokládá, že předplatné Připojení ivity již existuje.
Další kroky
Projděte si oblast návrhu sítí a připojení v architektuře Azure Well-architected Framework.
Související prostředky
Kromě služeb Azure používaných v základní architektuře jsou tyto služby pro tuto architekturu důležité.