Vad är Azure Resource Manager?

  • Artikel

Azure Resource Manager är Azures tjänst för distribution och hantering. Den ger dig ett hanteringslager där du kan skapa, uppdatera och ta bort resurser i ditt Azure-konto. Du kan använda hanteringsfunktioner som åtkomstkontroll, lås och taggar till att skydda och organisera dina resurser efter distributionen.

Mer information om Azure Resource Manager-mallar (ARM-mallar) finns i översikten över ARM-mallen. Mer information om Bicep finns i översikten över Bicep.

I följande video beskrivs grundläggande begrepp i Azure Resource Manager.

Enhetligt hanteringslager

När du skickar en begäran via någon av Azure-API:erna, verktygen eller SDK:erna tar Resource Manager emot begäran. Den autentiserar och auktoriserar begäran innan den vidarebefordras till lämplig Azure-tjänst. Eftersom alla förfrågningar hanteras via samma API visas enhetliga resultat och funktionerna i de olika verktygen.

Följande bild visar vilken roll Azure Resource Manager har i hanteringen av Azure-förfrågningar.

Diagram that shows the role of Azure Resource Manager in handling Azure requests.

Alla funktioner som är tillgängliga i portalen är även tillgängliga via PowerShell, Azure CLI, REST-API:er och klient-SDK:er. Funktioner som ursprungligen släpptes via API:er representeras i portalen inom 180 dagar efter den första versionen.

Viktigt!

Azure Resource Manager stöder endast TLS (Transport Layer Security) 1.2 eller senare senast hösten 2023. Mer information finns i Migrera till TLS 1.2 för Azure Resource Manager.

Terminologi

Om du inte har arbetat med Azure Resource Manager tidigare finns det några termer som kanske är nya för dig.

  • resurs – Ett hanterbart objekt som är tillgängligt via Azure. Virtuella datorer, lagringskonton, webbappar, databaser och virtuella nätverk är exempel på resurser. Resursgrupper, prenumerationer, hanteringsgrupper och taggar är också exempel på resurser.
  • resursgrupp – En container som innehåller relaterade resurser för en Azure-lösning. En resursgrupp innehåller de resurser du vill hantera som en grupp. Du bestämmer vilka resurser som ska ingå i en resursgrupp baserat på vad som är bäst för organisationen. Se Vad är en resursgrupp?.
  • resursprovider – en tjänst som tillhandahåller Azure-resurser. En vanlig resursprovider är Microsoft.Computetill exempel , som tillhandahåller resursen för den virtuella datorn. Microsoft.Storage är en annan vanlig resursprovider. Se Resursprovidrar och typer.
  • deklarativ syntax – Syntax som låter dig ange "Här är vad jag tänker skapa" utan att behöva skriva sekvensen med programmeringskommandon för att skapa den. ARM-mallar och Bicep-filer är exempel på deklarativ syntax. I dessa filer definierar du egenskaperna för infrastrukturen som ska distribueras till Azure.
  • ARM-mall – en JSON-fil (JavaScript Object Notation) som definierar en eller flera resurser som ska distribueras till en resursgrupp, prenumeration, hanteringsgrupp eller klientorganisation. Mallen kan användas för att distribuera resurserna på ett konsekvent sätt och upprepade gånger. Se Översikt över malldistribution.
  • Bicep-fil – en fil för deklarativ distribution av Azure-resurser. Bicep är ett språk som har utformats för att ge den bästa redigeringsupplevelsen för infrastruktur som kodlösningar i Azure. Se översikt över Bicep.
  • extension resource – en resurs som lägger till en annan resurss funktioner. En rolltilldelning är till exempel en tilläggsresurs. Du tillämpar en rolltilldelning på andra resurser för att ange åtkomst. Se Tilläggsresurser.

Fler definitioner av Azure-terminologi finns i Grundläggande begrepp i Azure.

Fördelarna med att använda Resource Manager

Med Resource Manager kan du göra följande:

  • Hantera din infrastruktur via deklarativa mallar i stället för skript.

  • Distribuera, hantera och övervaka alla resurser för din lösning som en grupp, snarare än att hantera resurserna individuellt.

  • Du kan distribuera om lösningen under utvecklingens livscykel och vara trygg i att resurserna distribueras i ett konsekvent tillstånd.

  • Definiera beroenden mellan resurser så att de distribueras i rätt ordning.

  • Tillämpa åtkomstkontroll på alla tjänster eftersom rollbaserad åtkomstkontroll i Azure (Azure RBAC) är inbyggt integrerad i hanteringsplattformen.

  • Märka upp resurser och organisera alla resurser i din prenumeration logiskt.

  • Förtydliga organisationens fakturering genom att visa kostnader för en grupp av resurser med samma tagg.

Förstå omfång

Azure tillhandahåller fyra nivåer av hanteringsomfång: hanteringsgrupper, prenumerationer, resursgrupper och resurser. Följande bild visar ett exempel på de här nivåerna.

Diagram that illustrates the four levels of scope in Azure: management groups, subscriptions, resource groups, and resources.

Du tillämpar hanteringsinställningar på någon av de här omfångsnivåerna. Vilken nivå du väljer avgör hur brett inställningen tillämpas. Lägre nivåer ärver inställningar från högre nivåer. När du till exempel tillämpar en princip på prenumerationen tillämpas principen på alla resursgrupper och resurser i din prenumeration. När du tillämpar en princip på resursgruppen tillämpas den principen på resursgruppen och alla dess resurser. Policyn gäller dock inte för andra resursgrupper.

Information om hur du hanterar identiteter och åtkomst finns i Microsoft Entra-ID.

Du kan distribuera mallar till klientorganisationer, hanteringsgrupper, prenumerationer och resursgrupper.

Vad är en resursgrupp?

En resursgrupp är en container som gör att du kan hantera relaterade resurser för en Azure-lösning. Med hjälp av resursgruppen kan du samordna ändringar i de relaterade resurserna. Du kan till exempel distribuera en uppdatering till resursgruppen och vara säker på att resurserna uppdateras i en samordnad åtgärd. Eller när du är klar med lösningen kan du ta bort resursgruppen och veta att alla resurser tas bort.

Det finns några viktiga faktorer att tänka på när du definierar en resursgrupp:

  • Alla resurser i resursgruppen bör dela samma livscykel. Du distribuerar, uppdaterar och tar bort dem tillsammans. Om en resurs, till exempel en server, måste finnas i en annan distributionscykel bör den finnas i en annan resursgrupp.

  • Varje resurs kan endast finnas i en resursgrupp.

  • Du kan lägga till eller ta bort en resurs i en resursgrupp när som helst.

  • Du kan flytta en resurs från en resursgrupp till en annan grupp. Mer information finns i Flytta resurser till en ny resursgrupp eller prenumeration.

  • Resurserna i en resursgrupp kan finnas i andra regioner än resursgruppen.

  • När du skapar en resursgrupp måste du ange en plats för den resursgruppen.

    Du kanske undrar, "varför behöver en resursgrupp en plats? Och om resurserna kan ha andra platser än resursgruppen, varför spelar platsen för gruppresursen alls någon roll?"

    Resursgruppen lagrar metadata om resurserna. När du anger en plats för resursgruppen anger du var metadata lagras. På grund av regelefterlevnadsskäl kan du behöva säkerställa att dina data lagras inom en viss region.

    För att säkerställa tillståndskonsekvens för resursgruppen dirigeras alla kontrollplansåtgärder via resursgruppens plats. När du väljer en resursgruppsplats rekommenderar vi att du väljer en plats nära den plats där kontrollåtgärderna kommer. Vanligtvis är den här platsen den som är närmast din aktuella plats. Det här routningskravet gäller endast för kontrollplansåtgärder för resursgruppen. Det påverkar inte begäranden som skickas till dina program.

    Om en resursgrupps region är tillfälligt otillgänglig kanske du inte kan uppdatera resurser i resursgruppen eftersom metadata inte är tillgängliga. Resurserna i andra regioner fungerar fortfarande som förväntat, men du kanske inte kan uppdatera dem. Det här villkoret kan också gälla globala resurser som Azure DNS, Privata Azure DNS-zoner, Azure Traffic Manager och Azure Front Door. Du kan visa vilka typer som har sina metadata hanterade av Azure Resource Manager via listan över typer för azure resource graph-resurstabellen.

    Mer information om hur du skapar tillförlitliga program finns i Designa tillförlitliga Azure-program.

  • En resursgrupp kan användas för att definiera omfattningen av åtkomstkontrollen för administrativa åtgärder. Om du vill hantera en resursgrupp kan du tilldela Azure-principer, Azure-roller eller resurslås.

  • Du kan använda taggar för en resursgrupp. Resurserna i resursgruppen ärver inte dessa taggar.

  • En resurs kan ansluta till resurser i andra resursgrupper. Det här scenariot är vanligt när de två resurserna är relaterade men inte delar samma livscykel. Du kan till exempel ha en webbapp som ansluter till en databas i en annan resursgrupp.

  • När du tar bort en resursgrupp tas även alla resurser i resursgruppen bort. Information om hur Azure Resource Manager samordnar dessa borttagningar finns i Azure Resource Manager-resursgrupp och resursborttagning.

  • Du kan distribuera upp till 800 instanser av en resurstyp i varje resursgrupp. Vissa resurstyper är undantagna från instansgränsen på 800. Mer information finns i begränsningar för resursgrupper.

  • Vissa resurser kan finnas utanför en resursgrupp. Dessa resurser distribueras till prenumerationen, hanteringsgruppen eller klientorganisationen. Endast specifika resurstyper stöds i dessa omfång.

  • Om du vill skapa en resursgrupp kan du använda portalen, PowerShell, Azure CLI eller en ARM-mall.

Återhämtning i Azure Resource Manager

Azure Resource Manager-tjänsten är utformad för återhämtning och kontinuerlig tillgänglighet. Resource Manager- och kontrollplansåtgärder (begäranden som skickas till management.azure.com) i REST-API:et är:

  • Distribuerad mellan regioner. Azure Resource Manager har en separat instans i varje region i Azure, vilket innebär att ett fel i Azure Resource Manager-instansen i en region inte påverkar tillgängligheten för Azure Resource Manager eller andra Azure-tjänster i en annan region. Även om Azure Resource Manager är distribuerat mellan regioner är vissa tjänster regionala. Den här skillnaden innebär att även om den inledande hanteringen av kontrollplansåtgärden är motståndskraftig kan begäran vara känslig för regionala avbrott när den vidarebefordras till tjänsten.

  • Distribueras över Tillgänglighetszoner (och regioner) på platser som har flera Tillgänglighetszoner. Den här fördelningen säkerställer att När en region förlorar en eller flera zoner kan Azure Resource Manager antingen redundansväxla till en annan zon eller till en annan region för att fortsätta att tillhandahålla kontrollplansfunktioner för resurserna.

  • Inte beroende av ett enda logiskt datacenter.

  • Tas aldrig ner för underhållsaktiviteter.

Den här motståndskraften gäller för tjänster som tar emot begäranden via Resource Manager. Key Vault drar till exempel nytta av den här återhämtningsförmågan.

Platsjustering för resursgrupp

För att minska effekten av regionala avbrott rekommenderar vi att du hittar resurser i samma region som resursgruppen.

Platsen för resursgruppen är den plats där Azure Resource Manager lagrar metadata för resurserna i resursgruppen. Azure Resource Manager använder den här platsen för routning och cachelagring. När du till exempel visar en lista över dina resurser i prenumerations- eller resursgruppsomfången hämtar Azure Resource Manager informationen från cachen.

När resursgruppens region inte är tillgänglig kan Azure Resource Manager inte uppdatera resursens metadata och blockera dina skrivanrop. Genom att samplacera resurs- och resursgruppsregionen minskar du risken för att regionen inte är tillgänglig eftersom dina resurser och metadata finns i en region i stället för flera regioner.

Lösa samtidiga åtgärder

När två eller flera åtgärder försöker uppdatera samma resurs samtidigt identifierar Azure Resource Manager konflikten och tillåter endast en åtgärd att slutföras. Azure Resource Manager blockerar de andra åtgärderna och returnerar ett fel.

Samtidiga resursuppdateringar kan orsaka oväntade resultat. Den här lösningen säkerställer att dina uppdateringar är deterministiska och tillförlitliga. Du känner till statusen för dina resurser och undviker eventuella inkonsekvenser eller dataförluster.

Anta att du har två begäranden (A och B) som försöker uppdatera samma resurs samtidigt. Om begäran A slutförs innan begäran B, lyckas begäran A och begäran B misslyckas. Begäran B returnerar 409-felet. När du har fått den felkoden kan du hämta resursens uppdaterade status och avgöra om du vill skicka begäran B igen.

Nästa steg