Wat is Azure Resource Manager?

  • Artikel
  • 7 minuten om te lezen

Azure Resource Manager is de implementatie- en beheersservice voor Azure. Het biedt een beheerlaag waarmee u resources in uw Azure-account kunt maken, bijwerken en verwijderen. U kunt beheerfuncties gebruiken, zoals toegangscontrole, vergrendelingen en tags, om uw resources te beveiligen en te organiseren na de implementatie.

Zie overzicht van ARM-sjablonen voor meer informatie over Azure Resource Manager-sjablonen (ARM-sjablonen). Zie Overzicht van Bicep voor meer informatie over Bicep.

Consistente beheerlaag

Wanneer u een aanvraag verzendt via een van de Azure-API's, hulpprogramma's of SDK's, ontvangt Resource Manager de aanvraag. De aanvraag wordt geverifieerd en geautoriseerd voordat deze naar de juiste Azure-service wordt doorgestuurd. Omdat alle aanvragen worden verwerkt via dezelfde API, ziet u consistente resultaten en mogelijkheden in de verschillende hulpprogramma's.

In de volgende afbeelding ziet u welke rol Azure Resource Manager speelt bij het verwerken van Azure-aanvragen.

Resource Manager-aanvraagmodel

Alle mogelijkheden die beschikbaar zijn in de Azure-portal zijn ook beschikbaar via Azure PowerShell, Azure CLI, de Azure REST API's en client-SDK's. Functionaliteit die oorspronkelijk wordt uitgegeven via API's, is binnen 180 dagen na de eerste release beschikbaar in de portal.

Belangrijk

Azure Resource Manager biedt in de herfst van 2023 alleen ondersteuning voor Transport Layer Security (TLS) 1.2 of hoger. Zie Migreren naar TLS 1.2 voor Azure Resource Manager voor meer informatie.

Terminologie

Als u nog geen ervaring hebt met de Azure Resource Manager, zijn er enkele termen die u mogelijk niet kent.

  • resource - een beheerbaar item dat beschikbaar is via Azure. Virtuele machines, opslagaccounts, web-apps, databases en virtuele netwerken zijn voorbeelden van resources. Resourcegroepen, abonnementen, beheergroepen en tags zijn ook voorbeelden van resources.
  • resourcegroep - een container met gerelateerde resources voor een Azure-oplossing. De resourcegroep bevat die resources die u als groep wilt beheren. U bepaalt welke resources in een resourcegroep horen op basis van wat voor uw organisatie het meest zinvol is. Zie Resourcegroepen.
  • resourceprovider - een service die zorgt voor Azure-resources. Een veelgebruikte resourceprovider is bijvoorbeeld Microsoft.Compute, die de virtuele machine levert. Microsoft.Storage is een andere veel voorkomende resourceprovider. Zie Resourceproviders en -typen.
  • declaratieve syntaxis : syntaxis waarmee u kunt aangeven dat dit het volgende moet worden gemaakt zonder dat u de reeks programmeeropdrachten hoeft te schrijven om deze te maken. ARM-sjablonen en Bicep-bestanden zijn voorbeelden van declaratieve syntaxis. In deze bestanden definieert u de eigenschappen voor de infrastructuur die moet worden geïmplementeerd in Azure.
  • ARM-sjabloon : een JSON-bestand (JavaScript Object Notation) waarmee een of meer resources worden gedefinieerd die moeten worden geïmplementeerd in een resourcegroep, abonnement, beheergroep of tenant. De sjabloon kan worden gebruikt om de resources consistent en herhaaldelijk te implementeren. Zie Overzicht van sjabloonimplementatie.
  • Bicep-bestand : een bestand voor het declaratief implementeren van Azure-resources. Bicep is een taal die is ontworpen om de beste ontwerpervaring te bieden voor infrastructuur als codeoplossingen in Azure. Zie Bicep-overzicht.

Zie Basisconcepten van Azure voor meer definities van Azure-terminologie.

De voordelen van Resource Manager

Met Resource Manager kunt u het volgende doen:

  • Uw infrastructuur beheren via declaratieve sjablonen in plaats van scripts.

  • Alle resources voor uw oplossing implementeren, beheren en bewaken als groep, in plaats van deze resources afzonderlijk te verwerken.

  • Uw oplossing gedurende de ontwikkelingscyclus herhaaldelijk implementeren en erop vertrouwen dat de resources consistent worden geïmplementeerd.

  • De afhankelijkheden tussen resources zo definiëren dat deze in de juiste volgorde worden geïmplementeerd.

  • Toegangsbeheer toepassen op alle services omdat op rollen gebaseerde toegangscontrole van Azure (Azure RBAC) is geïntegreerd in het beheerplatform.Toegangsbeheer toepassen op alle services omdat op rollen gebaseerd toegangsbeheer (RBAC) is geïntegreerd in het beheerplatform.

  • Tags toepassen op de resources om alle resources in uw abonnement op een logische manier te organiseren.

  • De facturering van uw organisatie transparanter maken door te kijken naar de kosten voor een groep resources met dezelfde tag.

Bereik

Azure biedt vier bereikniveaus: beheergroepen, abonnementen, resourcegroepen en resources. In de volgende afbeelding ziet u een voorbeeld van deze lagen.

Beheerniveaus

U past beheerinstellingen toe op een of meer bereikniveaus. Het niveau dat u kiest, bepaalt de reikwijdte van de instelling. Lagere niveaus nemen instellingen over van hogere niveaus. Als u een beleid bijvoorbeeld toepast op het abonnement, wordt het beleid toegepast op alle resourcegroepen en resources in het abonnement. Wanneer u een beleid toepast op de resourcegroep, wordt dit beleid toegepast op de resourcegroep en alle bijbehorende resources. Een andere resourcegroep heeft deze beleidstoewijzing echter niet.

Zie Azure Active Directory voor informatie over het beheren van identiteiten en toegang.

U kunt sjablonen implementeren in tenants, beheergroepen, abonnementen of resourcegroepen.

Resourcegroepen

Er zijn een aantal belangrijke factoren waarmee u rekening moet houden bij het definiëren van de resourcegroep:

  • Alle resources in uw groep moeten dezelfde levenscyclus hebben. U implementeert ze samen, werkt ze samen bij en verwijdert ze samen. Als een bepaalde resource, zoals een server, onderdeel moet zijn van een andere implementatiecyclus, moet deze in een andere resourcegroep worden geplaatst.

  • Elke resource kan maar in één resourcegroep voorkomen.

  • U kunt een resource op elk gewenst moment toevoegen aan of verwijderen uit een resourcegroep.

  • U kunt een resource van de ene naar de andere resourcegroep verplaatsen. Zie voor meer informatie Resources verplaatsen naar een nieuwe resourcegroep of een nieuw abonnement.

  • De resources in een resourcegroep kunnen zich in andere regio's bevinden dan de resource groep.

  • Wanneer u een resourcegroep maakt, moet u een locatie voor die resourcegroep opgeven.

    U vraagt zich misschien af: 'Waarom heeft een resourcegroep een locatie nodig? En als de resources andere locaties kunnen hebben dan de resourcegroep, wat is dan het nut van een locatie voor de resourcegroep?'

    De resourcegroep slaat metagegevens op over de resources. Als u een locatie voor de resourcegroep opgeeft, geeft u op waar deze metagegevens worden opgeslagen. In verband met nalevingsvereisten moet u er mogelijk voor zorgen dat uw gegevens worden opgeslagen in een bepaalde regio.

    Om statusconsistentie voor de resourcegroep te garanderen, worden alle besturingsvlakbewerkingen gerouteerd via de locatie van de resourcegroep. Wanneer u een resourcegroeplocatie selecteert, raden we u aan een locatie te selecteren dicht bij waar uw besturingsbewerkingen vandaan komen. Normaal gesproken is deze locatie de locatie die het dichtst bij uw huidige locatie ligt. Deze routeringsvereiste is alleen van toepassing op besturingsvlakbewerkingen voor de resourcegroep. Dit heeft geen invloed op aanvragen die naar uw toepassingen worden verzonden.

    Als de regio van een resourcegroep tijdelijk niet beschikbaar is, kunt u resources in de resourcegroep niet bijwerken omdat de metagegevens niet beschikbaar zijn. De resources in andere regio's werken nog steeds zoals verwacht, maar u kunt ze niet bijwerken. Deze voorwaarde is niet van toepassing op globale resources zoals Azure Content Delivery Network, Azure DNS, Azure DNS Private Zones, Azure Traffic Manager en Azure Front Door.

    Zie Betrouwbare Azure-toepassingen ontwerpen voor meer informatie over het bouwen van betrouwbare toepassingen.

  • Een resourcegroep kan worden gebruikt voor het bepalen van de mate van toegangsbeheer voor beheertaken. Als u een resourcegroep wilt beheren, kunt u Azure-beleidsregels, Azure-rollenof resourcevergrendelingen toewijzen.

  • U kunt tags toepassen op een resourcegroep. De resources in de resourcegroep nemen deze tags niet over.

  • Een resource kan verbinding maken met resources in andere resourcegroepen. Dit scenario is gebruikelijk wanneer de twee resources gerelateerd zijn, maar niet dezelfde levenscyclus hebben. U kunt bijvoorbeeld een web-app hebben die verbinding maakt met een database in een andere resourcegroep.

  • Wanneer u een resourcegroep verwijdert, worden ook alle resources in de resourcegroep verwijderd. Zie Azure Resource Manager-resourcegroep en het verwijderen van resourcesvoor meer informatie over hoe Azure Resource Manager deze verwijdert.

  • U kunt maximaal 800 exemplaren van een resourcetype implementeren in elke resourcegroep. Sommige resourcetypen worden uitgesloten van de limiet van 800 exemplaren. Zie limieten voor resourcegroepen voor meer informatie.

  • Sommige resources kunnen buiten een resourcegroep bestaan. Deze resources worden geïmplementeerd in het abonnement, de beheergroep of de tenant. In deze bereiken worden alleen specifieke resourcetypen ondersteund.

  • Als u een resourcegroep wilt maken, kunt u de portal, PowerShell, Azure CLI of een ARM-sjabloon gebruiken.

Tolerantie van Azure Resource Manager

De Azure Resource Manager-service is ontworpen voor tolerantie en voortdurende beschikbaarheid. Resource Manager-bewerkingen en besturingsvlakbewerkingen (aanvragen die zijn verzonden naar management.azure.com) in de REST API zijn:

  • Gedistribueerd over verschillende regio's. Hoewel Azure Resource Manager is verdeeld over regio's, zijn sommige services regionaal. Dit onderscheid betekent dat hoewel de eerste afhandeling van de besturingsvlakbewerking tolerant is, de aanvraag mogelijk vatbaar is voor regionale storingen wanneer deze wordt doorgestuurd naar de service.

  • Verdeeld over Beschikbaarheidszones (en regio's) op locaties met meerdere Beschikbaarheidszones.

  • Niet afhankelijk van één logisch datacentrum.

  • Nooit offline gezet voor onderhoudsactiviteiten.

Deze tolerantie is van toepassing op services die aanvragen ontvangen via Resource Manager. Key Vault heeft bijvoorbeeld voordelen vanwege deze tolerantie.

Volgende stappen