Partager via

Qu’est-ce qu’Azure Resource Manager ?

  • Article

Azure Resource Manager est le service de déploiement et de gestion d’Azure. Il fournit une couche de gestion qui vous aide à créer, de mettre à jour et de supprimer des ressources dans votre compte Azure. Vous pouvez utiliser des fonctionnalités de gestion telles que le contrôle d’accès, les verrous et les étiquettes pour sécuriser et organiser vos ressources après le déploiement.

La vidéo suivante présente les bases de Resource Manager :

Couche de gestion cohérente

Quand vous envoyez une demande à partir d’un outil, d’une API ou d’un kit SDK Azure, Resource Manager reçoit la demande. Il authentifie et autorise la demande avant de la transférer au service Azure approprié. Comme toutes les demandes sont gérées via la même API, vous voyez des résultats cohérents et des capacités cohérentes dans tous les différents outils.

Le diagramme suivant montre le rôle que Resource Manager joue pendant les requêtes Azure :

Diagramme montrant le rôle de Resource Manager durant les requêtes Azure.

Toutes les fonctionnalités qui sont disponibles dans le portail Azure sont également disponibles via PowerShell, Azure CLI, les API REST et les SDK clients. Lorsque les API introduisent de nouvelles fonctionnalités, cela reflète dans le portail dans les 180 jours suivant la version initiale.

Important

Resource Manager ne prendra plus en charge les protocoles antérieurs à TLS 1.2 le 1er mars 2025. Pour plus d’informations, consultez Migrations vers TLS 1.2 pour Azure Resource Manager.

Terminologie

Si vous êtes un nouvel utilisateur de Resource Manager, il se peut que vous ne connaissiez pas les termes suivants :

  • Ressource : un élément gérable disponible via Azure. Les exemples de ressources comprennent les machines virtuelles, les comptes de stockage, les applications web, les bases de données et les réseaux virtuels. Les groupes de ressources, les abonnements, les groupes d’administration et les étiquettes sont également des ressources.

  • groupe de ressources : conteneur réunissant les ressources associées d’une solution Azure. Le groupe de ressources inclut les ressources que vous voulez gérer en tant que groupe. Vous déterminez quelles sont les ressources qui appartiennent à un groupe de ressources en fonction de ce qui convient le mieux à votre organisation. Consultez Qu’est-ce qu’un groupe de ressources ?

  • fournisseur de ressources : service qui fournit des ressources Azure. Par exemple, Microsoft.Compute est un fournisseur de ressources courant, qui fournit la ressource de machine virtuelle. Microsoft.Storage est un autre fournisseur de ressources courant. Voir Fournisseurs et types de ressources Azure.

  • syntaxe déclarative : syntaxe qui vous permet de déclarer « Voici ce que je souhaite créer », sans avoir à écrire la séquence de commandes de programmation pour le créer. Les modèles ARM et les fichiers Bicep sont des exemples de syntaxe déclarative. Dans ces fichiers, vous définissez les propriétés afin de déployer l’infrastructure vers Azure.

  • Modèle ARM : un fichier JSON (JavaScript Object Notation) qui définit une ou plusieurs ressources à déployer sur un groupe de ressources, un abonnement, un groupe de gestion ou un abonné. Utilisez le modèle pour déployer les ressources de manière cohérente et répétée. Consultez Quels sont les modèles ARM ? pour obtenir une vue d’ensemble de la façon de déployer des modèles.

  • Fichier Bicep : un fichier pour le déploiement déclaratif des ressources Azure. Bicep est un langage conçu pour fournir la meilleure expérience de création de solutions infrastructure en tant que code dans Azure. Consultez Qu’est-ce que Bicep ? pour en savoir plus sur Bicep.

  • Ressource d’extension : ressource qui ajoute des fonctionnalités à une autre ressource. Par exemple, l’attribution de rôle est un type de ressource d’extension. Vous appliquez une attribution de rôle à toute autre ressource pour spécifier l’accès. Consultez Ressources d’extension.

Pour d’autres définitions de la terminologie Azure, consultez Concepts fondamentaux Azure.

Avantages de l’utilisation de Resource Manager

Avec Resource Manager, vous pouvez :

  • Gérer votre infrastructure à l’aide de modèles déclaratifs plutôt que de scripts

  • Déployer, gérer et superviser toutes les ressources de votre solution sous forme de groupe, plutôt qu’individuellement

  • Redéployer votre solution tout au long du cycle de vie de développement et vérifier que vos ressources sont déployées dans un état cohérent

  • Définir les dépendances entre les ressources pour qu’elles soient déployées dans le bon ordre

  • Appliquer le contrôle d’accès à tous les services, car le contrôle d’accès en fonction du rôle Azure (Azure RBAC) est intégré de manière native à la plateforme de gestion.

  • Appliquer des étiquettes aux ressources pour organiser de manière logique toutes les ressources de votre abonnement

  • Clarifiez la facturation de votre organisation en affichant les coûts d’un groupe de ressources qui partagent une même étiquette.

Comprendre la portée

Azure fournit quatre niveaux d’étendue de gestion : Groupes d’administration, Abonnements, Groupes de ressource et Ressources. Le diagramme suivant visualise ces couches :

Diagramme illustrant les quatre niveaux d’étendue dans Azure : groupes d’administration, abonnements, groupes de ressource et ressources.

Vous appliquez les paramètres de gestion à tous ces niveaux de l’étendue. Le niveau que vous sélectionnez détermine à quel point le paramètre est appliqué. Les niveaux inférieurs héritent des paramètres des niveaux supérieurs. Par exemple, Lorsque vous appliquez une stratégie à l’abonnement, cette stratégie est appliquée à tous les groupes de ressources et les ressources de votre abonnement. Lorsque vous appliquez une stratégie au groupe de ressources, elle est appliquée au groupe de ressources et à toutes ses ressources. Toutefois, un autre groupe de ressources ne dispose pas de cette affectation de stratégie.

Consultez Qu’est-ce que Microsoft Entra ID ? pour en savoir plus sur la gestion des identités et des accès dans Azure.

Vous pouvez déployer des modèles sur des locataires, des groupes d’administration, des abonnements ou des groupes de ressources.

Présentation des groupes de ressources

Un groupe de ressources est un conteneur que vous utilisez pour gérer les ressources associées d’une solution Azure. L’utilisation d’un groupe de ressources peut vous aider à coordonner les modifications entre les ressources associées. Par exemple, vous pouvez déployer une mise à jour sur tout le groupe de ressources avec l’assurance que l’opération se fasse de manière coordonnée. Ou, lorsque vous en avez terminé avec une solution, vous pouvez supprimer le groupe de ressources concerné en sachant que toutes les ressources sont supprimées.

Lorsque vous définissez votre groupe de ressources, il existe des considérations importantes :

  • Toutes les ressources de votre groupe de ressources doivent partager le même cycle de vie. Les opérations de déploiement, de mise à jour et de suppression porteront sur toutes les ressources du groupe. Par exemple, un serveur est une ressource. Si elle doit exister dans un autre cycle de déploiement, elle doit se trouver à un autre groupe de ressources.

  • Chaque ressource ne peut exister que dans un seul groupe de ressources.

  • Vous pouvez à tout moment ajouter ou supprimer une ressource au niveau d’un groupe de ressources.

  • Vous pouvez déplacer une ressource d’un groupe de ressources vers un autre groupe. Pour plus d’informations, consultez Déplacer des ressources Azure vers un nouveau groupe de ressources ou abonnement.

  • Les ressources d’un groupe de ressources peuvent être situées dans des régions différentes de celles du groupe de ressources, mais nous vous recommandons d’utiliser le même emplacement. Consultez Quel emplacement dois-je utiliser pour mon groupe de ressources ?.

  • Un groupe de ressources peut être utilisé pour définir l’étendue du contrôle d’accès des actions administratives. Vous pouvez utiliser des stratégies, des rôles ou des verrous de ressources Azure pour gérer un groupe de ressources.

  • Vous pouvez appliquer des étiquettes à un groupe de ressources. Les ressources présentes dans le groupe de ressources n’héritent pas de ces étiquettes.

  • Une ressource peut se connecter à des ressources se trouvant dans d’autres groupes de ressources. Ce scénario est courant quand les deux ressources sont liées mais qu’elles ne partagent pas le même cycle de vie. Par exemple, vous pouvez avoir une application web qui se connecte à une base de données se trouvant dans un groupe de ressources différent.

  • Quand vous supprimez un groupe de ressources, toutes les ressources présentes dans ce groupe sont également supprimées. Pour obtenir des informations sur la façon dont Resource Manager orchestre ces suppressions, consultez Suppression d’un groupe de ressources et de ressources Azure Resource Manager.

  • Vous pouvez déployer jusqu’à 800 instances d’un type de ressource dans chaque groupe de ressources. Certains types de ressources sont exemptés de la limite de 800 instances. Pour plus d’informations, consultez les limites du groupe de ressources.

  • Certaines ressources peuvent exister en dehors d’un groupe de ressources. Ces ressources sont déployées dans l’abonnement, le groupe d’administration ou le locataire. Seuls des types de ressources spécifiques sont pris en charge dans ces étendues.

  • Pour créer un groupe de ressources, utilisez le portail Azure, PowerShell, Azure CLI ou un modèle ARM.

Quel emplacement dois-je utiliser pour mon groupe de ressources ?

Quand vous créez un groupe de ressources, vous devez indiquer une localisation pour ce groupe.

Vous pouvez vous demander pourquoi un groupe de ressources a besoin d’un emplacement et pourquoi l’emplacement du groupe de ressources importe si les ressources peuvent avoir des emplacements en dehors d’un groupe de ressources.

Le groupe de ressources stocke des métadonnées sur les ressources. Lorsque vous spécifiez un emplacement pour le groupe de ressources, vous indiquez également où stocker ces métadonnées. Pour des raisons de conformité, vous devrez peut-être vous assurer que vos données sont stockées dans une région spécifique.

L'acheminement de toutes les opérations du plan de contrôle via l'emplacement du groupe de ressources peut aider le groupe de ressources à rester dans un état cohérent. Lorsque vous sélectionnez un emplacement de groupe de ressources, il est recommandé de sélectionner un emplacement proche de l’origine de vos opérations de contrôle. En règle générale, cette localisation est la plus proche de votre emplacement actuel. Cette exigence de routage s’applique uniquement aux opérations de plan de contrôle pour le groupe de ressources. Cela n’affecte pas les demandes envoyées à vos applications.

Si la région d’un groupe de ressources n’est pas disponible temporairement, il se peut que vous ne puissiez pas mettre à jour les ressources du groupe de ressources, car les métadonnées ne sont pas disponibles. Les ressources des autres régions continueront de fonctionner comme prévu, mais vous pourriez peut-être ne pas être ne mesure de les mettre à jour. Cette condition pourrait également s’appliquer aux ressources globales telles qu’Azure DNS, Azure Private DNS zones, Azure Traffic Manager et Azure Front Door. Consultez la table Azure Resource Graph et la liste de référence de type de ressource pour afficher les ressources et les métadonnées gérées par Resource Manager.

Lorsqu’une région du groupe de ressources n’est pas disponible, Resource Manager ne peut pas mettre à jour les métadonnées de votre ressource et bloque vos appels en écriture. Pour réduire l’impact des pannes régionales, il est recommandé de placer vos ressources et le groupe de ressources dans la même région. Cela réduit la probabilité qu’une région ne soit pas disponible, car vos ressources et métadonnées existent dans une région au lieu de plusieurs.

Pour plus d’informations sur la création d’applications fiables, consultez la liste de contrôle de résilience pour des services Azure spécifiques.

Résilience de Resource Manager

Resource Manager est conçu pour assurer résilience et disponibilité continue. Les opérations Resource Manager et du plan de contrôle (demandes envoyées à management.azure.com) dans l’API REST :

  • Répartir entre les différentes régions. Resource Manager dispose d’une instance distincte dans chaque région d’Azure, ce qui signifie que si une instance Azure Resource Manager échoue dans une région, cela n’a pas d’impact sur la disponibilité du service dans une autre région ; la même chose s’applique à d’autres services Azure. Bien que Resource Manager soit distribué entre les régions, certains services sont régionaux. Cette distinction signifie que, même si la gestion initiale de l’opération de plan de contrôle est résiliente, la requête peut être susceptible à des pannes régionales lorsqu’elle est transférée au service.

  • Distribue dans différentes zones de disponibilité (et régions) dans des emplacements avec plusieurs zones de disponibilité. Cette distribution garantit que lorsqu’une région perd une ou plusieurs zones, Resource Manager peut basculer vers une autre zone ou région. L’application continue de fournir une fonctionnalité de plan de contrôle pour les ressources.

  • Ne dépendez pas d’un centre de données logique.

  • Ne sont pas arrêtées pour des activités de maintenance.

Cette résilience s’applique aux services qui reçoivent des demandes par le biais de Resource Manager. Azure Key Vault est un service qui bénéficie de cette cohérence.

Résoudre les opérations simultanées

Les mises à jour simultanées des ressources peuvent entraîner des résultats inattendus. Lorsque deux opérations ou plus tentent de mettre à jour la même ressource en même temps, Resource Manager détecte le conflit, autorise une seule opération à se terminer correctement, bloque les autres opérations et renvoie une erreur. Cette résolution garantit que vos mises à jour sont concluantes et fiables ; vous connaissez l’état de vos ressources et évitez toute incohérence ou perte de données.

Par exemple, si vous avez deux requêtes (A et B) qui essaient de mettre à jour la même ressource en même temps et que la requête A se termine avant la demande B, la requête A réussit et la demande B échoue. La requête B retourne l’erreur 409. Après avoir obtenu ce code d’erreur, vous pouvez obtenir l’état mis à jour de la ressource et déterminer si vous souhaitez envoyer la requête B à nouveau.

Étapes suivantes