Qu’est-ce qu’Azure Blueprints (préversion) ?

Important

Azure Blueprints (version préliminaire) sera retiré le 31 janvier 2027, avec un retrait progressif à compter du 31 juillet 2026. Migrez vos définitions et attributions de Blueprint existantes vers Deployment Stacks (recommandé) et Template Specs. Les artefacts de blueprint sont convertis en modèles JSON ARM ou en fichiers Bicep utilisés pour définir des piles de déploiement. Pour connaître la chronologie, l’impact et le FAQ en phases complètes, consultez Azure Blueprints mise hors service ou https://aka.ms/AzureBlueprintsRetirement. Pour savoir comment créer un artefact en tant que ressource ARM, consultez :

Tip

Pour vous aider dans votre migration depuis Azure Blueprints, la compétence de migration Azure Blueprints pour GitHub Copilot fournit des conseils pour l’évaluation de l’inventaire, l’exportation de ressources, la conversion d’artefacts en spécifications de modèles et piles de déploiement, la validation et le cutover.

La compétence est un contenu d’exemple sous licence MIT. Ce n'est pas un produit ou service Microsoft, et il n'est couvert par aucun accord de niveau de service Azure ni accord de support. La compétence dirige un assistant IA, dont la sortie est non déterministe et peut être inexacte ou incomplète, et elle peut générer des commandes qui suppriment définitivement les définitions de plans, les affectations et d’autres ressources. Examinez, comprenez et testez tout ce qu’il génère dans un abonnement hors production avant de l’exécuter. Pour les termes complets, consultez les avis juridiques et les avertissements.

À l’instar d’un plan, « blueprint » en anglais, qui permet aux ingénieurs et architectes de décrire les paramètres de conception d’un projet, Azure Blueprint permet aux architectes cloud et aux membres de l’informatique centrale de définir un ensemble reproductible de ressources Azure qui implémentent et respectent les normes, modèles et exigences d’une organisation. Azure Blueprints permet aux équipes de développement de créer et de déployer rapidement de nouveaux environnements, avec l’assurance qu’ils respectent la conformité de l’organisation, grâce à un ensemble de composants intégrés, tels que la mise en réseau, afin d’accélérer le développement et la livraison.

Les blueprints sont un moyen déclaratif d’orchestrer le déploiement de divers modèles de ressources et d’autres artefacts, notamment ceux-ci :

  • Affectations de rôles
  • Attributions de stratégies
  • Modèles Azure Resource Manager (modèles ARM)
  • Groupes de ressources

Le service Azure Blueprints est soutenu par le service globalement distribué Azure Cosmos DB. Les objets Blueprint sont répliqués dans plusieurs régions Azure. Cette réplication offre une faible latence, une haute disponibilité et un accès cohérent à vos objets blueprint, quelle que soit la région dans laquelle Azure Blueprints déploie vos ressources.

En quoi cela diffère des modèles ARM

Le service est conçu pour faciliter la configuration de l’environnement. Cette configuration se compose souvent d’un ensemble de groupes de ressources, de stratégies, d’attributions de rôles et de déploiements de modèles ARM. Un blueprint est un package qui vous permet de regrouper ces types d’artefact. Vous pouvez composer ce package et gérer ses versions, notamment par le biais d’un pipeline CI/CD (intégration continue/livraison continue). En fin de compte, chacun est attribué à un abonnement en une seule opération pouvant être auditée et suivie.

Presque tout ce que vous souhaitez inclure pour le déploiement dans Azure Blueprints peut être réalisé à l’aide d’un modèle ARM. Toutefois, un modèle ARM est un document qui n’existe pas de manière native dans Azure ; chacun est stocké soit localement, soit dans la gestion de code source, soit dans Modèles (préversion). Le modèle peut servir aux déploiements d’une ou plusieurs ressources Azure, mais une fois ces ressources déployées, il n’existe aucune connexion et relation active au modèle.

Avec Azure Blueprints, la relation entre la définition du blueprint (ce qui doit être déployé) et l’affectation du blueprint (ce qui a été déployé) est conservée. Cette connexion prend en charge le suivi et l’audit améliorés des déploiements. Azure Blueprints peut également mettre à niveau plusieurs abonnements régis par le même blueprint simultanément.

Il n'est pas nécessaire de choisir entre un modèle ARM et un plan directeur. Chaque blueprint peut comprendre zéro ou plusieurs artefacts d’un modèle Resource Manager. Cette prise en charge signifie que les efforts précédents visant à développer et à maintenir une bibliothèque de modèles ARM peuvent être réutilisés dans Azure Blueprints.

Différences par rapport à Azure Policy

Un blueprint est un package ou un conteneur qui permet de composer des ensembles spécifiques de normes, modèles et exigences en rapport avec l’implémentation de services cloud Azure, de stratégies de sécurité et de conceptions réutilisables à des fins de cohérence et de conformité.

Une stratégie est un système d’autorisations par défaut et de refus explicites qui s’applique aux propriétés des ressources durant le déploiement et aux ressources existantes. Il prend en charge la gouvernance du cloud en validant que les ressources d’un abonnement respectent les exigences et les normes.

L’inclusion d’une stratégie dans un blueprint permet de créer le bon modèle ou la bonne conception lors de l’affectation du blueprint. L’inclusion d’une stratégie garantit que seules des modifications approuvées ou attendues peuvent être apportées à l’environnement afin de maintenir la conformité continue avec l’intention du modèle.

Une stratégie peut constituer l’un des nombreux artefacts d’une définition de blueprint. Les blueprints prennent également en charge l’utilisation de paramètres avec des stratégies et des initiatives.

Définition de blueprint

Un blueprint est composé d’artefacts. Azure Blueprints prend actuellement en charge les ressources suivantes comme artefacts :

Ressource Options de hiérarchie Description
Groupes de ressources Abonnement Créer un groupe de ressources devant être utilisé par d’autres artefacts du modèle. Ces groupes de ressources fictifs vous permettent d’organiser les ressources exactement comme vous souhaitez les structurer et fournissent également une restriction de portée pour les artefacts inclus de stratégie et d’attribution de rôles, ainsi que pour les modèles ARM.
Modèle ARM Abonnement, groupe de ressources Des modèles, tels que les modèles imbriqués et liés, sont utilisés pour composer des environnements complexes. Exemples d’environnements : une batterie de serveurs SharePoint, la Configuration d’état d’Azure Automation ou un espace de travail Log Analytics.
Attribution de stratégie Abonnement, groupe de ressources Permet l’affectation d’une stratégie ou d’une initiative à l’abonnement auquel le blueprint est affecté. La stratégie ou l’initiative doit se trouver à l’intérieur de l’étendue de l’emplacement de définition du blueprint. Si la stratégie ou l’initiative comporte des paramètres, ces paramètres sont définis lors de la création du blueprint ou lors de son attribution.
Attribution de rôle Abonnement, groupe de ressources Ajoutez un utilisateur ou un groupe existant à un rôle intégré pour vous assurer que les personnes adéquates disposent d’un accès approprié à vos ressources. Vous pouvez définir des attributions de rôle pour l’ensemble de l’abonnement ou les imbriquer dans un groupe de ressources spécifique inclus dans le blueprint.

Remarque

Chaque artefact doit être inférieur ou égal à 2 Mo. Si l’artefact dépasse 2 Mo, vous obtenez une erreur HTTP 500 (Erreur interne du serveur).

Emplacements de définition du blueprint

Quand vous créez une définition de blueprint, vous définissez l’emplacement d’enregistrement du blueprint. Les blueprints peuvent être enregistrés dans un groupe d’administration ou dans un abonnement auquel vous avez accès en tant que Contributeur. Si l’emplacement est un groupe d’administration, le blueprint peut être affecté à n’importe quel abonnement enfant de ce groupe d’administration.

Paramètres de blueprint

Les plans peuvent transmettre des paramètres à une stratégie ou à une initiative, ou à un modèle ARM. Lors de l’ajout de artifact à un plan, l’auteur choisit soit de fournir une valeur définie pour chaque affectation de plan, soit de permettre à chaque affectation de plan de fournir une valeur au moment de l’affectation. Cette flexibilité permet de définir une valeur prédéterminée pour toutes les utilisations du modèle ou de faire prendre cette décision lors de l’attribution.

Remarque

Un blueprint peut avoir ses propres paramètres, mais leur création n’est actuellement possible que si le blueprint est généré à partir de l’API REST (impossible si le blueprint est généré par le biais du portail).

Pour plus d’informations, consultez Paramètres de blueprint.

Publication de plans

Quand vous créez un blueprint, celui-ci est initialement en mode Brouillon. Lorsqu’il est prêt à être attribué, il doit être Publié. La publication nécessite la définition d’une Version (chaîne composée de lettres, de chiffres et de traits d’union d’une longueur maximale de 20 caractères) avec, en option, des Notes de changement. La Version permet de le distinguer des modifications futures apportées à ce même plan et permet d’attribuer chaque version. Ce contrôle de version vous permet donc d’affecter différentes Versions du même blueprint au même abonnement. Lorsque des changements sont apportés au blueprint, la Versionpubliée est toujours présente, ainsi que les Changements non publiés. Une fois les modifications terminées, le plan mis à jour est publié avec une version nouvelle et unique, et peut désormais aussi être attribué.

Attribution de modèle

Chaque versionpubliée d’un blueprint peut être affectée (avec une longueur maximale de 90 caractères pour le nom) à un groupe d’administration ou un abonnement existant. Dans le portail, le modèle définit par défaut la Version sur celle publiée le plus récemment. Si des paramètres d’artefact ou des paramètres de blueprint sont présents, ils sont définis durant le processus d’affectation.

Remarque

L’affectation d’une définition de blueprint à un groupe d’administration signifie que l’objet d’affectation existe dans le groupe d’administration. Le déploiement d’artefacts cible toujours un abonnement. Pour effectuer une affectation de groupe d’administration, l’API REST Créer ou Mettre à jour doit être utilisée et le corps de la demande doit inclure une valeur pour properties.scope afin de définir l’abonnement cible.

Autorisations dans Azure Blueprint

Gérez les autorisations du plan via le contrôle d’accès en fonction du rôle Azure (Azure RBAC).

Vous n'avez pas besoin d'une autorisation RBAC dédiée Azure pour lire ou afficher une définition de blueprint. Les définitions de blueprint sont destinées à être détectables par les principaux qu’ils régissent. Par conséquent, tout principal authentifié dans le locataire peut répertorier et lire les définitions de blueprint étendues au groupe d’administration, leurs versions et leurs artefacts, y compris via l’API REST, même sans attribution de rôle sur ce groupe d’administration. La lecture d’une définition de blueprint stockée dans un abonnement nécessite un accès en lecture à cet abonnement. La création, la publication, l’attribution, la mise à jour et la suppression de blueprints nécessitent toujours les autorisations décrites dans cet article.

Important

Comme tout principal authentifié du locataire peut lire les définitions de plan, ne stockez pas de secrets ni d’autres informations sensibles directement dans une définition de plan ou dans ses paramètredefaultValues. Pour les secrets, utilisez secureString ou utilisez des secureObject paramètres soutenus par des références Azure Key Vault, qui conservent la valeur secrète dans Key Vault au lieu du blueprint.

Pour créer des blueprints, votre compte doit avoir les autorisations suivantes :

  • Microsoft.Blueprint/blueprints/write - Créer une définition de blueprint
  • Microsoft.Blueprint/blueprints/artifacts/write - Créer des artefacts à partir d’une définition de modèle
  • Microsoft.Blueprint/blueprints/versions/write - Publier un blueprint

Pour supprimer des blueprints, votre compte doit avoir les autorisations suivantes :

  • Microsoft.Blueprint/blueprints/delete
  • Microsoft.Blueprint/blueprints/artifacts/delete
  • Microsoft.Blueprint/blueprints/versions/delete

Remarque

Les autorisations de définition du blueprint doivent être accordées ou héritées sur l’étendue de l’abonnement ou du groupe d’administration où il est enregistré.

Pour affecter ou annuler l’affectation d’un blueprint, votre compte doit avoir les autorisations suivantes :

  • Microsoft.Blueprint/blueprintAssignments/write - Attribuer un modèle
  • Microsoft.Blueprint/blueprintAssignments/delete - Annuler l’affectation d’un blueprint

Remarque

Comme les affectations de blueprint sont créées sur un abonnement, les autorisations d’affectation de blueprint et d’annulation d’affectation de blueprint doivent être accordées sur une étendue d’abonnement ou être héritées dans une étendue d’abonnement.

Les rôles intégrés suivants sont disponibles :

Rôle Azure Description
Propriétaire En plus d’autres autorisations, inclut toutes les autorisations relatives à Azure Blueprints.
Contributeur En plus d’autres autorisations, permet de créer et supprimer des définitions de blueprint, mais ne dispose pas des autorisations d’affectation de blueprint.
Contributeur au plan Peut gérer les définitions blueprint, mais ne peut pas les affecter.
Opérateur de plans Peut attribuer des modèles publiés existants, mais ne peut pas créer de nouvelles définitions de modèles. L’affectation de blueprints ne fonctionne que si elle est effectuée avec une identité managée attribuée par l’utilisateur.

Si ces rôles intégrés ne répondent pas à vos besoins de sécurité, songez à créer un rôle personnalisé.

Remarque

Si vous utilisez une identité managée affectée par le système, le principal de service pour Azure Blueprint nécessite le rôle Propriétaire sur l’abonnement affecté pour pouvoir activer le déploiement. Si vous utilisez le portail, ce rôle est automatiquement accordé et révoqué pour le déploiement. Si vous utilisez l’API REST, ce rôle doit être accordé manuellement, mais il est toujours automatiquement révoqué une fois le déploiement terminé. En cas d’utilisation d’une identité managée affectée par l’utilisateur, seul l’utilisateur qui crée l’affectation de blueprint a besoin de l’autorisation Microsoft.Blueprint/blueprintAssignments/write, qui est incluse à la fois dans les rôles intégrés Propriétaire et Opérateur blueprint.

Limites de nommage

Les limitations suivantes existent pour certains champs :

Objet Champ Caractères autorisés Max. Longueur
Schéma directeur Nom lettres, chiffres, traits d’union et traits de soulignement 48
Schéma directeur Version lettres, chiffres, traits d’union et points 20
Attribution de modèle Nom lettres, chiffres, traits d’union et traits de soulignement 90
Artefact de schéma Nom lettres, chiffres, traits d’union et points 48

Présentation vidéo

La présentation suivante d’Azure Blueprints est issue d’Azure Friday. Pour télécharger la vidéo, accédez à Azure Fridays - An overview of Azure Blueprints sur Channel 9.

Mise hors service d’Azure Blueprints

Azure Blueprints (version préliminaire) est mis hors service le 31 janvier 2027, avec une mise hors service progressive à compter du 31 juillet 2026. Migrez vos définitions et vos affectations de blueprint vers Azure Deployment Stacks (recommandé) et les spécifications de modèle avant la date de mise hors service. Pour obtenir des instructions sur la chronologie, l’impact et la migration par phases, consultez :

Étapes suivantes

  • Last updated on