Implementatiebereiken begrijpen
Virtuele machines, logische Azure SQL-servers en -databases, opslagaccounts, virtuele netwerken en de meeste andere Azure-resources moeten in een resourcegroep worden geplaatst. Sommige resources kunnen echter op een andere manier worden geïmplementeerd. Deze resources worden gewoonlijk gebruikt om het gedrag van uw Azure-omgeving te beheren.
In deze les bekijkt u de hiërarchie van Azure-resources en bekijkt u hoe bepaalde resources in verschillende bereiken kunnen worden geïmplementeerd.
De Azure-resourcehiërarchie
Azure heeft een hiërarchische resourcestructuur met meerdere beheerniveaus. Hier volgt een diagram waarin wordt getoond hoe uw speelgoedbedrijf de Azure-omgeving kan organiseren:
Uw tenant komt overeen met uw Microsoft Entra-exemplaar. Een organisatie heeft doorgaans slechts één Exemplaar van Microsoft Entra. Dit exemplaar fungeert als de hoofdmap van de resourcehiërarchie.
Beheergroepen bieden een manier om Azure-abonnementen te organiseren. Elke tenant heeft één hoofdbeheergroep en u kunt uw eigen hiërarchie van beheergroepen eronder instellen. U kunt afzonderlijke beheergroepen maken voor de verschillende onderdelen van uw organisatie of voor abonnementen met hun eigen beveiligings- of governancevereisten. U kunt beperkingen voor beleid en toegangsbeheer toepassen op beheergroepen en alle abonnementen onder die beheergroep in de hiërarchie nemen deze beperkingen over. Beheergroepen worden niet geïmplementeerd in regio's en hebben geen invloed op de locaties van uw resources.
Abonnementen fungeren als factureringsaccounts en ze bevatten resourcegroepen en resources. Net als beheergroepen hebben abonnementen geen locatie en beperken ze niet waar uw resources worden geïmplementeerd.
Resourcegroepen zijn logische containers voor uw resources. Met resourcegroepen kunt u gerelateerde resources beheren en beheren als één eenheid. Resources zoals virtuele machines, Azure-app Service-abonnementen, opslagaccounts en virtuele netwerken moeten in een resourcegroep worden geplaatst. Resourcegroepen worden gemaakt op een locatie, zodat Azure de metagegevens voor de resources in de groep kan bijhouden, maar resources binnen de groep kunnen worden geïmplementeerd op andere locaties.
Het eerder geïllustreerde voorbeeld is een redelijk eenvoudig scenario dat laat zien hoe u beheergroepen kunt gebruiken. Uw organisatie kan ook overwegen om een landingszone te implementeren. Dit is een set Azure-resources en -configuratie die u nodig hebt om aan de slag te gaan met een Azure-productieomgeving. De landingszone op ondernemingsniveau is een bewezen benadering voor het gebruik van beheergroepen en abonnementen om uw Azure-resources effectief te beheren:
Ongeacht het model dat u volgt, door inzicht te krijgen in de verschillende niveaus van de hiërarchie, kunt u flexibele besturingselementen toepassen op de wijze waarop uw Azure-omgeving wordt gebruikt en beheerd. Met Bicep kunt u deze besturingselementen beheren met alle voordelen van infrastructuur als code.
Notitie
Er zijn ook enkele andere resources die zijn geïmplementeerd op specifieke bereiken. Extensieresources worden geïmplementeerd binnen het bereik van een andere Azure-resource. Een resourcevergrendeling is bijvoorbeeld een extensieresource, die wordt geïmplementeerd in een resource, zoals een opslagaccount.
U bent al bekend met het implementeren van resources in resourcegroepen, dus laten we eens kijken naar de andere bereiken voor implementatie.
Resources binnen het abonnementsbereik
U kunt resources implementeren in een abonnement wanneer:
- U moet een nieuwe resourcegroep maken. Een resourcegroep is eigenlijk alleen een resource binnen het abonnementsbereik.
- U moet toegang verlenen tot alle resources binnen een abonnement. Als uw HR-afdeling bijvoorbeeld een Azure-abonnement heeft dat alle Azure-resources van de afdeling bevat, kunt u roltoewijzingen maken zodat iedereen in de HR-afdeling de inhoud van het abonnement kan lezen.
- U gebruikt Azure Policy en u wilt een beleid definiëren of toepassen op alle resources binnen het abonnement. De R&D-afdeling van uw speelgoedbedrijf heeft u bijvoorbeeld gevraagd een beleid te implementeren dat de lijst met SKU's voor virtuele machines beperkt die kunnen worden gemaakt binnen het abonnement van het team.
Resources binnen het bereik van beheergroepen
U kunt resources implementeren in een beheergroep wanneer:
U moet toegang verlenen tot alle resources binnen abonnementen die onder de hiërarchie van de beheergroep vallen. Uw cloudbewerkingsteam kan bijvoorbeeld toegang nodig hebben tot elk abonnement in uw organisatie. U kunt een roltoewijzing maken in uw hoofdbeheergroep, waarmee uw cloudbewerkingsteam toegang verleent tot alles in Azure.
Let op
Wees uiterst voorzichtig wanneer u toegang verleent tot resources met behulp van beheergroepen, en met name de hoofdbeheergroep. Houd er rekening mee dat elke resource onder de beheergroep in de hiërarchie de roltoewijzing over neemt. Zorg ervoor dat uw organisatie de best practices voor identiteitsbeheer en verificatie volgt en dat deze het principe van minimale bevoegdheden volgt; Dat wil gezegd, verleent u geen toegang die niet is vereist.
U moet beleidsregels toepassen in uw hele organisatie. Uw organisatie kan bijvoorbeeld een beleid hebben dat resources in bepaalde geografische regio's in geen geval kunnen worden gemaakt. U kunt een beleid toepassen op uw hoofdbeheergroep die het maken van resources in die regio blokkeert.
Notitie
Voordat u beheergroepen voor het eerst gebruikt, moet u deze instellen voor uw Azure-omgeving.
Resources binnen tenantbereik
U kunt resources implementeren in uw tenant wanneer:
U moet Azure-abonnementen maken. Wanneer u beheergroepen gebruikt, bevinden abonnementen zich onder beheergroepen in de resourcehiërarchie, maar wordt een abonnement geïmplementeerd als een resource binnen tenantbereik.
Notitie
Niet alle Azure-klanten kunnen abonnementen maken met infrastructuur als code. Afhankelijk van uw factureringsrelatie met Microsoft, is dit mogelijk niet mogelijk. Zie Programmatisch Azure-abonnementen maken voor meer informatie.
U maakt of configureert beheergroepen. Azure maakt één hoofdbeheergroep wanneer u beheergroepen voor uw tenant inschakelt en u kunt er meerdere niveaus van beheergroepen onder maken. U kunt Bicep gebruiken om uw hele beheergroephiërarchie te definiëren. U kunt ook abonnementen toewijzen aan beheergroepen.
Met Bicep kunt u implementaties verzenden naar het tenantbereik. Implementaties met tenantbereik vereisen speciale machtigingen. In de praktijk hoeft u echter geen implementaties met tenantbereik in te dienen. Het is eenvoudiger om in plaats daarvan resources met tenantbereik te implementeren met behulp van een sjabloon in een ander bereik. Verderop in deze module ziet u hoe u dit doet.
Tip
U kunt geen beleidsregels of roltoewijzingen maken in het tenantbereik. Als u echter toegang wilt verlenen of beleidsregels wilt toepassen in uw hele organisatie, kunt u deze resources implementeren in de hoofdbeheergroep.
Resource-id's
U bent nu bekend met resource-id's voor resources die zich in abonnementen bevinden. Hier ziet u bijvoorbeeld een resource-id die een resourcegroep vertegenwoordigt. Dit is een resource binnen het bereik van een abonnement:
/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyDevelopment
Hier volgt een visuele weergave van dezelfde informatie:
Abonnementen zelf hebben hun eigen id's, zoals deze:
/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c
Notitie
Hoewel abonnementen worden beschouwd als onderliggende beheergroepen, bevatten hun resource-id's geen beheergroep-id. Azure houdt de relatie tussen abonnementen en beheergroepen bij op een manier die verschilt van andere resourcerelaties. Dit biedt u de flexibiliteit om abonnementen tussen beheergroepen te verplaatsen zonder dat u alle resource-id's hoeft te wijzigen.
Wanneer u met resources werkt in een beheergroep of tenantbereik, kunnen resource-id's er iets anders uitzien dan normaal. Ze volgen meestal het standaardpatroon van het interleaving van het resourcetype met de informatie over uw specifieke resources. De specifieke indeling is echter afhankelijk van de resource waarmee u werkt.
Hier volgt een voorbeeld van een resource-id voor een beheergroep:
/providers/Microsoft.Management/managementGroups/ProductionMG
Dit ziet er als volgt uit:
Notitie
Beheergroepen hebben zowel een id als een weergavenaam. De weergavenaam is een door mensen leesbare beschrijving van de beheergroep. U kunt de weergavenaam wijzigen zonder dat dit van invloed is op de id van de beheergroep.
Wanneer een resource wordt geïmplementeerd in een beheergroepbereik, bevat de bijbehorende resource-id de beheergroep-id. Hier volgt een voorbeeld van een resource-id voor een roldefinitie die is gemaakt in een bereik van een beheergroep:
/providers/Microsoft.Management/managementGroups/ProductionMG/providers/Microsoft.Authorization/roleDefinitions/d79b8492-6f38-49f9-99e6-b2e667d4f3ca
Hier volgt een visuele weergave van dezelfde id:
Er kan een andere roldefinitie worden gedefinieerd voor een abonnementsbereik, zodat de resource-id er iets anders uitziet:
/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/providers/Microsoft.Authorization/roleDefinitions/d79b8492-6f38-49f9-99e6-b2e667d4f3ca
Hier volgt een visuele weergave van dezelfde id:
Nu u de Azure-resourcehiërarchie en de typen resources begrijpt die u op elk bereik kunt implementeren, kunt u beslissingen nemen over de bereiken waarop u uw resources wilt implementeren. U kunt bijvoorbeeld een geïnformeerde keuze maken over of u een beleidsdefinitie moet maken binnen het bereik van een resourcegroep, abonnement of beheergroep. In de volgende les leert u hoe u Bicep-bestanden maakt die zijn gericht op elk van deze bereiken.