Co je Azure Resource Manager?

Azure Resource Manager je služba nasazování a správy pro Azure. Poskytuje úroveň správy, která vám umožňuje vytvářet, aktualizovat a odstraňovat prostředky v účtu Azure. Pomocí funkcí správy, jako jsou řízení přístupu, zámky a značky, můžete zabezpečit a organizovat prostředky po nasazení.

Další informace o šablonách Azure Resource Manageru (šablony ARM) najdete v přehledu šablon ARM. Další informace o nástroji Bicep najdete v přehledu bicep.

Následující video popisuje základní koncepty Azure Resource Manageru.

Konzistentní vrstva správy

Když odešlete požadavek prostřednictvím libovolného rozhraní API, nástrojů nebo sad SDK Azure, Resource Manager žádost obdrží. Před předáním žádosti příslušné službě Azure ověří a autorizuje ji. Vzhledem k tomu, že se všechny požadavky zpracovávají přes stejné rozhraní API, zobrazí se konzistentní výsledky a možnosti ve všech různých nástrojích.

Následující obrázek ukazuje, jakou roli hraje Azure Resource Manager při zpracování požadavků Azure.

Diagram znázorňující roli Azure Resource Manageru při zpracování požadavků Azure

Všechny funkce, které jsou k dispozici na portálu, jsou také dostupné prostřednictvím PowerShellu, rozhraní Azure CLI, rozhraní REST API a klientských sad SDK. Funkce, které byly původně vydány prostřednictvím rozhraní API, jsou na portálu reprezentovány do 180 dnů od počáteční verze.

Důležité

Azure Resource Manager bude podporovat pouze protokol TLS (Transport Layer Security) 1.2 nebo novější do podzimu 2023. Další informace najdete v tématu Migrace na protokol TLS 1.2 pro Azure Resource Manager.

Terminologie

Pokud s Azure Resource Managerem začínáte, existuje několik termínů, které možná neznáte.

  • prostředek - Spravovatelná položka, která je k dispozici prostřednictvím služby Azure. Mezi příklady prostředků patří virtuální počítače, účty úložiště, webové aplikace, databáze a virtuální sítě. Příklady prostředků jsou také skupiny prostředků, předplatná, skupiny pro správu a značky.
  • skupina prostředků – Kontejner, který obsahuje související prostředky pro řešení Azure. Skupina prostředků zahrnuje ty prostředky, které chcete spravovat jako skupinu. O tom, které prostředky do skupiny prostředků patří, rozhodujete vy na základě toho, co je pro vaši organizaci nejvhodnější. Podívejte se, co je skupina prostředků?
  • poskytovatel prostředků – služba, která poskytuje prostředky Azure. Běžným poskytovatelem prostředků je Microsoft.Computenapříklad poskytovatel prostředků, který poskytuje prostředek virtuálního počítače. Microsoft.Storage je dalším běžným poskytovatelem prostředků. Viz poskytovatelé a typy prostředků.
  • deklarativní syntaxe – Syntaxe, která vám umožní uvést " Zde je to, co mám v úmyslu vytvořit", aniž byste museli psát posloupnost programovacích příkazů k jeho vytvoření. Příkladem deklarativní syntaxe jsou šablony ARM a soubory Bicep. V těchto souborech definujete vlastnosti infrastruktury, která se má nasadit do Azure.
  • Šablona ARM – soubor JSON (JavaScript Object Notation), který definuje jeden nebo více prostředků pro nasazení do skupiny prostředků, předplatného, skupiny pro správu nebo tenanta. Šablony lze použít k nasazení prostředků konzistentně a opakovaně. Viz přehled nasazení šablony.
  • Soubor Bicep – Soubor pro deklarativní nasazení prostředků Azure Bicep je jazyk, který byl navržen tak, aby poskytoval nejlepší prostředí pro vytváření obsahu pro infrastrukturu jako řešení kódu v Azure. Viz přehled Bicep.
  • prostředek rozšíření – prostředek, který se přidá k možnostem jiného prostředku. Například přiřazení role je prostředek rozšíření. Přiřazení role použijete u jakéhokoli jiného prostředku k určení přístupu. Viz prostředky rozšíření.

Další definice terminologie Azure najdete v základních konceptech Azure.

Výhody použití Resource Manageru

Pomocí Resource Manageru můžete:

  • Spravovat infrastrukturu prostřednictvím deklarativních šablon místo skriptů.

  • Nasadit, spravovat a sledovat veškeré prostředky pro vaše řešení jako skupinu, nemusíte s nimi pracovat samostatně.

  • Opětovně nasadit řešení v celém průběhu vývojového životního cyklu a mít jistotu, že se vaše prostředky nasazují konzistentně.

  • Definovat závislosti mezi prostředky, aby se nasazovaly ve správném pořadí.

  • Použití řízení přístupu u všech služeb, protože řízení přístupu na základě role v Azure (Azure RBAC) je nativně integrováno do platformy pro správu.

  • Používat značky pro prostředky, abyste logicky uspořádali všechny prostředky ve vašem předplatném.

  • Objasnit si fakturaci organizace zobrazením nákladů za skupinu prostředků sdílejících stejnou značku.

Orientace v oborech

Azure poskytuje čtyři úrovně rozsahu správy: skupiny pro správu, předplatná, skupiny prostředků a prostředky. Následující obrázek ukazuje příklad těchto vrstev.

Diagram znázorňující čtyři úrovně rozsahu v Azure: skupiny pro správu, předplatná, skupiny prostředků a prostředky

Nastavení správy použijete na kterékoli z těchto úrovní oboru. Vámi zvolená úroveň určuje, jak široce bude nastavení použito. Nižší úrovně dědí nastavení z vyšších úrovní. Když například použijete zásadu pro předplatné, použije se zásada pro všechny skupiny prostředků a prostředky ve vašem předplatném. Když použijete zásadu pro skupinu prostředků, použije se tato zásada na skupinu prostředků a všechny její prostředky. Jiná skupina prostředků ale toto přiřazení zásady nemá.

Informace o správě identit a přístupu naleznete v tématu Microsoft Entra ID.

Šablony můžete nasadit do klientů, skupin pro správu, předplatných nebo skupin prostředků.

Co je skupina prostředků?

Skupina prostředků je kontejner, který umožňuje spravovat související prostředky pro řešení Azure. Pomocí skupiny prostředků můžete koordinovat změny souvisejících prostředků. Můžete například nasadit aktualizaci do skupiny prostředků a mít jistotu, že se prostředky aktualizují v koordinované operaci. Nebo až budete s řešením hotovi, můžete odstranit skupinu prostředků a zjistit, že se odstraní všechny prostředky.

Při definování skupin prostředků byste měli vzít v úvahu některé důležité faktory:

  • Všechny prostředky ve vaší skupině prostředků by měly sdílet stejný životní cyklus. Nasazujete, aktualizujete a odstraňujete je společně. Pokud jeden prostředek, například server, musí existovat v jiném cyklu nasazení, měl by být v jiné skupině prostředků.

  • Každý prostředek může existovat jen v jedné skupině prostředků.

  • Prostředky je možné do skupiny prostředků kdykoli přidat nebo naopak odebrat.

  • Prostředky je možné přesouvat mezi skupinami. Další informace najdete v tématu, které se zabývá přesunutím prostředků do nové skupiny prostředků nebo předplatného.

  • Prostředky ve skupině prostředků se dají nacházet v různých oblastech, než je skupina prostředků, ale doporučujeme použít stejné umístění. Podívejte se , jaké umístění mám použít pro svoji skupinu prostředků?

  • Skupinu prostředků lze využít k určení rozsahu řízení přístupu pro akce správy. Ke správě skupiny prostředků můžete přiřadit zásady Azure, role Azure nebo zámky prostředků.

  • Značky můžete použít u skupiny prostředků. Prostředky ve skupině prostředků nezdědí tyto značky.

  • Prostředek se může připojit k prostředkům v jiných skupinách prostředků. Tento scénář je běžný v případě, že tyto dva prostředky souvisejí, ale nesdílejí stejný životní cyklus. Můžete mít například webovou aplikaci, která se připojuje k databázi v jiné skupině prostředků.

  • Když odstraníte skupinu prostředků, odstraní se také všechny prostředky ve skupině prostředků. Informace o tom, jak Azure Resource Manager tyto odstranění orchestruje, najdete v tématu Skupina prostředků a odstranění prostředků Azure Resource Manageru.

  • V každé skupině prostředků můžete nasadit až 800 instancí typu prostředku. Některé typy prostředků jsou vyloučené z limitu 800 instancí. Další informace najdete v tématu Omezení skupin prostředků.

  • Některé prostředky můžou existovat mimo skupinu prostředků. Tyto prostředky se nasazují do předplatného, skupiny pro správu nebo tenanta. V těchto oborech jsou podporovány pouze konkrétní typy prostředků.

  • K vytvoření skupiny prostředků můžete použít portál, PowerShell, Azure CLI nebo šablonu ARM.

Jaké umístění mám použít pro svoji skupinu prostředků?

Když vytvoříte skupinu prostředků, musíte pro tuto skupinu prostředků zadat umístění.

Asi vás zajímá, proč skupina prostředků potřebuje umístění. A proč vůbec záleží na umístění skupiny prostředků, pokud prostředky mohou mít jiná umístění než skupina prostředků.

Skupina prostředků ukládá metadata o prostředcích. Když zadáte umístění pro skupinu prostředků, určíte, kde jsou tato metadata uložena. Z důvodu dodržování předpisů může být nutné zajistit, aby se data ukládala v určité oblasti.

Aby se zajistila konzistence stavu pro skupinu prostředků, všechny operace řídicí roviny se směrují přes umístění skupiny prostředků. Při výběru umístění skupiny prostředků doporučujeme vybrat umístění blízko místa, odkud vaše řídicí operace pocházejí. Obvykle je toto umístění nejblíže k vašemu aktuálnímu umístění. Tento požadavek směrování se vztahuje pouze na operace řídicí roviny pro skupinu prostředků. Nemá vliv na požadavky, které se posílají do vašich aplikací.

Pokud je oblast skupiny prostředků dočasně nedostupná, možná nebudete moct aktualizovat prostředky ve skupině prostředků, protože metadata nejsou k dispozici. Prostředky v jiných oblastech stále fungují podle očekávání, ale možná je nebudete moct aktualizovat. Tato podmínka se může vztahovat také na globální prostředky, jako jsou Azure DNS, privátní zóny Azure DNS, Azure Traffic Manager a Azure Front Door. Můžete zobrazit, které typy mají svá metadata spravovaná Azure Resource Managerem, prostřednictvím seznamu typů pro tabulku prostředků Azure Resource Graphu.

Pokud chcete snížit dopad oblastních výpadků, doporučujeme vyhledat prostředky ve stejné oblasti jako skupina prostředků. Pokud oblast skupiny prostředků není dostupná, Azure Resource Manager nemůže aktualizovat metadata vašeho prostředku a blokuje volání zápisu. Díky společnému přidělení prostředku a oblasti skupiny prostředků snížíte riziko nedostupnosti oblastí, protože prostředky a metadata existují v jedné oblasti místo více oblastí.

Další informace o vytváření spolehlivých aplikací najdete v tématu Navrhování spolehlivých aplikací Azure.

Odolnost Azure Resource Manageru

Služba Azure Resource Manager je navržená pro odolnost a nepřetržitou dostupnost. Operace Resource Manageru a řídicí roviny (požadavky odeslané na management.azure.com) v rozhraní REST API jsou:

  • Distribuováno napříč oblastmi. Azure Resource Manager má v každé oblasti Azure samostatnou instanci, což znamená, že selhání instance Azure Resource Manageru v jedné oblasti nemá vliv na dostupnost Azure Resource Manageru nebo jiných služeb Azure v jiné oblasti. I když je Azure Resource Manager distribuovaný napříč oblastmi, některé služby jsou regionální. Toto rozlišení znamená, že zatímco počáteční zpracování operace řídicí roviny je odolné, může být požadavek náchylný k oblastním výpadkům při předání službě.

  • Distribuované napříč Zóny dostupnosti (a oblastmi) v umístěních s více Zóny dostupnosti. Tato distribuce zajišťuje, že když oblast ztratí jednu nebo více zón, Azure Resource Manager může převzít služby při selhání do jiné zóny nebo do jiné oblasti, aby pro prostředky nadále poskytovala možnosti řídicí roviny.

  • Nezávisí na jednom logickém datovém centru.

  • Nikdy se nespadá do údržby.

Tato odolnost se vztahuje na služby, které přijímají požadavky prostřednictvím Resource Manageru. Například Key Vault tuto odolnost přináší.

Řešení souběžných operací

Když se dvě nebo více operací pokusí aktualizovat stejný prostředek současně, Azure Resource Manager zjistí konflikt a povolí úspěšné dokončení pouze jedné operace. Azure Resource Manager blokuje ostatní operace a vrací chybu.

Souběžné aktualizace prostředků můžou způsobit neočekávané výsledky. Toto řešení zajišťuje, aby vaše aktualizace byly deterministické a spolehlivé. Znáte stav prostředků a vyhnete se jakékoli nekonzistence nebo ztrátě dat.

Předpokládejme, že máte dva požadavky (A a B), které se pokusí aktualizovat stejný prostředek najednou. Pokud se požadavek A dokončí před požadavkem B, žádost A proběhne úspěšně a požadavek B selže. Požadavek B vrátí chybu 409. Po získání tohoto kódu chyby můžete získat aktualizovaný stav prostředku a určit, jestli chcete znovu odeslat požadavek B.

Další kroky