Partage 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 permet de créer, de mettre à jour et de supprimer des ressources dans votre compte Azure. Vous utilisez 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.

Pour en savoir plus sur les modèles Azure Resource Manager (ARM), consultez la vue d’ensemble des modèles ARM. Pour en savoir plus sur Bicep, consultez Vue d’ensemble de Bicep.

La vidéo suivante présente les concepts de base d’Azure 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.

L’image suivante montre le rôle qu’Azure Resource Manager joue dans la gestion des requêtes Azure.

Diagramme montrant le rôle d’Azure Resource Manager dans la gestion des requêtes Azure.

Toutes les fonctionnalités disponibles dans le portail sont également disponibles via PowerShell, Azure CLI, les API REST et les SDK clients. Les fonctionnalités initialement publiées par le biais des API sont représentées dans le portail dans les 180 jours après la publication de la version initiale.

Important

Azure Resource Manager prendra uniquement en charge Transport Layer Security (TLS) 1.2 ou version ultérieure à compter de l’automne 2023. Pour plus d’informations, consultez Migrations vers TLS 1.2 pour Azure Resource Manager.

Terminologie

Si vous êtes un nouvel utilisateur d’Azure Resource Manager, vous pouvez ne pas connaître certains termes.

  • ressource : élément gérable disponible dans Azure. Les machines virtuelles, les comptes de stockage, les applications web, les bases de données et les réseaux virtuels sont des exemples de ressources. Les groupes de ressources, les abonnements, les groupes d’administration et les étiquettes sont également des exemples de 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. Consultez Fournisseurs et types de ressources.
  • 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é. Le modèle peut être utilisé pour déployer les ressources de manière cohérente et répétée. Consultez Vue d’ensemble du déploiement de 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 IaC (Infrastructure as Code) dans Azure. Consultez Vue d’ensemble de 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

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

Comprendre la portée

Azure fournit quatre niveaux d’étendue de gestion : Groupes d’administration, Abonnements, Groupes de ressource et Ressources. L’image suivante représente un exemple de 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.

Pour plus d’informations sur la gestion des identités et des accès, consultez Microsoft Entra ID.

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 qui vous permet de gérer les ressources associées d’une solution Azure. Grâce au groupe de ressources, vous pouvez coordonner les modifications apportées aux 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, vous devez prendre en compte certains facteurs importants :

  • 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. Si l’une des ressources, comme un serveur, 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 la page Déplacement de ressources vers un nouveau groupe de ressources ou un 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. Pour gérer un groupe de ressources, vous pouvez affecter des stratégies Azure, des rôles Azure ou des verrous 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 Azure 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, vous pouvez utiliser le portail, 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 vous demandez peut-être « Pourquoi un groupe de ressources a-t-il besoin un emplacement ? Et, si les ressources peuvent avoir des emplacements différents de celui du groupe de ressources, pourquoi l’emplacement du groupe de ressources a-t-il une importance ? ».

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 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 particulière.

Pour garantir la cohérence de l’état pour le groupe de ressources, toutes les opérations de plan de contrôle sont acheminées via l’emplacement du groupe de ressources. Lorsque vous sélectionnez un emplacement de groupe de ressources, nous vous recommandons de sélectionner un emplacement proche de l’origine de vos opérations de contrôle. En règle générale, cet emplacement est le 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 est temporairement indisponible, vous pouvez ne pas être en mesure de mettre à jour les ressources du groupe de ressources, car les métadonnées ne sont pas disponibles. Les ressources dans les autres régions continuent de fonctionner comme prévu, mais il se peut que vous ne puissiez pas les mettre à jour. Cette condition peut également s’appliquer aux ressources globales telles qu’Azure DNS, Azure DNS Private Zones, Azure Traffic Manager et Azure Front Door. Vous pouvez afficher les types dont les métadonnées sont gérées par Azure Resource Manager via la liste des types pour la table de ressources Azure Resource Graph.

Pour réduire l’impact des pannes régionales, nous vous recommandons de placer les ressources dans la même région que le groupe de ressources. Lorsque la région du groupe de ressources n’est pas disponible, Azure Resource Manager ne peut pas mettre à jour les métadonnées de votre ressource et bloque vos appels d’écriture. En plaçant vos ressources et groupes de ressources dans la même région, vous réduisez le risque d’indisponibilité de la région, car vos ressources et métadonnées existent dans une région au lieu de plusieurs régions.

Pour plus d’informations sur la conception d’applications fiables, consultez Concevoir des applications Azure fiables.

Résilience d’Azure Resource Manager

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

  • Distribuées dans différentes régions. Azure Resource Manager dispose d’une instance distincte dans chaque région d’Azure, ce qui signifie qu’une défaillance de l’instance Azure Resource Manager dans une région n’a pas d’impact sur la disponibilité d’Azure Resource Manager ou d’autres services Azure dans une autre région. Bien qu’Azure Resource Manager soit distribué entre les régions, certains services sont régionaux. Cette distinction signifie que lorsque la gestion initiale de l’opération de plan de contrôle est résiliente, la requête peut être susceptible aux pannes régionales lorsqu’elle est transférée au service.

  • Distribuées dans différentes zones de disponibilité (et régions) dans des emplacements qui ont plusieurs zones de disponibilité. Cette distribution garantit que lorsqu'une région perd une ou plusieurs zones, Azure Resource Manager peut basculer vers une autre zone ou vers une autre région pour continuer à fournir la capacité de plan de contrôle pour les ressources.

  • Non dépendantes d’un seul centre de données logique.

  • Jamais 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. Par exemple, Key Vault bénéficie de cette résilience.

Résoudre les opérations simultanées

Lorsque deux opérations ou plus tentent de mettre à jour la même ressource en même temps, Azure Resource Manager détecte le conflit et autorise une seule opération à se terminer correctement. Azure Resource Manager bloque les autres opérations et retourne une erreur.

Les mises à jour simultanées des ressources peuvent entraîner des résultats inattendus. Cette résolution garantit que vos mises à jour sont déterministes et fiables. Vous connaissez l’état de vos ressources et évitez toute incohérence ou perte de données.

Supposons que vous ayez deux requêtes (A et B) qui essaient de mettre à jour la même ressource en même temps. Si la requête A se termine avant la requête 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 renvoyer la demande B.

Étapes suivantes