Génération de modèles Bicep avec GitHub Copilot

Terminée

Tip

Pour plus d’informations, consultez l’onglet Texte et images !

Bicep est le langage propre au domaine de Microsoft pour le déploiement de ressources Azure. Il se compile pour Azure Resource Manager modèles JSON, mais il est plus lisible et concis. Bicep élimine le code rébarbatif d’Azure Resource Manager tout en conservant le modèle déclaratif.

Une définition de ressource Bicep de base ressemble à ceci :

param location string = 'eastus'
param storageAccountName string

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
  }
}

Trois points à remarquer : le @ symbole sépare le type de ressource de la version de l’API, les paramètres sont déclarés en haut et les références de ressources utilisent des noms symboliques plutôt que des ID de ressource. Ces schémas comptent lorsque vous examinez les résultats de Copilot.

Cette unité se concentre sur l’utilisation de Copilot pour générer, étendre et optimiser les modèles Bicep. Pour obtenir une présentation complète de Bicep, consultez Introduction à Bicep.

Génération de modèles à partir d’invites en langage naturel

Par défaut, Copilot génère du Bicep à partir de ses données d’entraînement. Aucun outil externe ni aucune donnée de schéma dynamique n’est impliquée. Pour les types de ressources courants avec des exigences spécifiques, cela produit déjà une sortie fiable.

Génération d’un modèle simple

Commencez par une requête ciblée sur une seule ressource pour voir ce que Copilot génère. Un prompt bien cadré comme celui-ci donne à Copilot tout ce dont il a besoin :

Generate a Bicep template for an Azure Storage Account with these requirements:
- Standard_LRS SKU
- StorageV2 kind
- HTTPS-only access enforced
- Minimum TLS version: TLS 1.2
- Blob soft delete enabled with 7-day retention
- Public blob access disabled
- Parameters for: storageAccountName, location (default: eastus),
  environment, owner, costCenter
- Apply tags using a tags object built from the environment, owner,
  and costCenter parameters
- Output the storage account's primary blob endpoint

Vous devez obtenir un fichier Bicep complet avec des paramètres, un bloc de ressources et une sortie. Validez-le immédiatement avec az bicep build avant toute autre chose.

Génération d’un modèle multi-ressources

La complexité augmente lorsque plusieurs ressources dépendent les unes des autres. Les références de ressources, où le nom symbolique d'une ressource apparaît dans les propriétés d'une autre ressource, sont où Copilot a parfois besoin de correction.

Essayez cette requête pour générer un ensemble cohérent de ressources :

Generate a Bicep template that deploys the following resources:
- An App Service Plan (Standard S1 SKU) on Linux
- An App Service (Web App) using Node 20 on the App Service Plan
- A Key Vault with RBAC authorization enabled and soft delete (90 days)
- A Role Assignment giving the Web App's system-assigned managed identity
  the "Key Vault Secrets User" role on the Key Vault
- Application settings on the Web App pointing to the Key Vault URI

Parameters: appName, location, environment, owner, costCenter
Use symbolic name references for all cross-resource dependencies.
Do not use hardcoded resource IDs.

Passez en revue le résultat afin d’identifier trois problèmes courants à ce niveau :

• Dépendancescirculaires : si deux ressources se référencent mutuellement, Bicep ne compile pas. Vérifiez le graphique des dépendances.
• l’étendue d’affectation de rôle : la ressource roleAssignment a besoin du Key Vault comme étendue, et non du groupe de ressources. Vérifiez la scope: propriété.
• Référence d’identité : webApp.identity.principalId est le bon moyen de référencer l’identité managée. Confirmez que Copilot utilise le nom symbolique, et non une valeur codée en dur.

Modularisation d’un modèle

À mesure que les modèles augmentent, ils deviennent plus difficiles à gérer. Les modules Bicep vous permettent de diviser un modèle volumineux en composants réutilisables. Copilot peut faire cette division pour vous.

Refactor this Bicep template into modules. Create:
- A module for the App Service Plan and Web App (modules/webapp.bicep)
- A module for the Key Vault and Role Assignment (modules/keyvault.bicep)
- A main.bicep that calls both modules and passes parameters between them

Show me the content of all three files. Ensure the output of the Key Vault
module (the Key Vault URI) is passed to the Web App module as an input.

Copilot génère les fichiers de module et le fichier d’orchestration principal. L’essentiel est de vérifier que les valeurs output d’un module sont correctement reliées aux entrées param d’un autre module. Cette connexion inter-modules est l’erreur la plus courante lors du fractionnement des modèles.

Bicep MCP : génération sensible au contexte

Qu’est-ce que MCP ?

Le protocole MCP (Model Context Protocol) est une norme ouverte qui permet aux modèles IA de se connecter aux outils et API externes. Au lieu de s’appuyer uniquement sur des données d’apprentissage, un Copilot compatible MCP peut interroger des sources de données actives en temps réel.

Le serveur MCP Bicep connecte GitHub Copilot au registre de type Bicep en direct. Grâce à cette connexion, GitHub Copilot a accès à :

• Versions actuelles de l’API pour chaque type de ressource Azure
• Schéma de propriété complet pour chaque type de ressource
• Règles de validation qui signalent des configurations incorrectes avant d’exécuter bicep build
• Avis de dépréciation lorsqu’une version d’une API est abandonnée

Sans MCP, Copilot génère du Bicep à partir de modèles issus de ses données d’entraînement. Ces données ont une date de coupure des connaissances et les versions d'API de Azure évoluent en continu. Le résultat peut être des modèles qui utilisent des versions d’API obsolètes, manquent les propriétés requises récemment ajoutées ou incluent des paramètres déconseillés. Avec MCP actif, Copilot interroge le registre en direct avant de générer chaque bloc de ressources.

Activation du serveur MCP Bicep

1. Dans VS Code, ouvrez la palette de commandes (Ctrl+Shift+P).
2. Recherchez MCP : Activez Bicep Server.
3. Vérifiez que le serveur s’affiche comme actif dans la barre d’état Copilot.

Une fois activé, Copilot Chat utilise automatiquement le serveur MCP Bicep lorsque vous travaillez sur des fichiers .bicep ou demandez-lui des ressources Bicep.

Ce qui change lorsque MCP est actif

La même requête, exécutée avec et sans MCP, produit un résultat nettement différent dans trois domaines.

Versions de l’API

Sans MCP, Copilot peut générer :

resource firewall 'Microsoft.Network/azureFirewalls@2022-07-01' = {

Avec MCP, Copilot interroge le Registre et génère la version stable actuelle :

resource firewall 'Microsoft.Network/azureFirewalls@2024-03-01' = {

Les versions plus récentes de l’API incluent souvent des améliorations de sécurité, de nouvelles propriétés requises et des correctifs de bogues.

Propriétés requises

Certains types de ressources ont obtenu des propriétés requises dans les versions plus récentes de l’API. Sans MCP, Copilot peut produire un modèle qui s’génère localement, mais échoue pendant le déploiement lorsque Azure valide la requête. Avec MCP, Copilot connaît ces exigences et les inclut.

Validation pendant la génération

Lorsque MCP est activé, Copilot peut signaler des problèmes avant que vous n’exécutiez bicep build. Si vous écrivez un nom de propriété qui n'existe pas dans le schéma, Copilot pouvez l'identifier immédiatement, comme IntelliSense pour un langage typé.

Exemple : réseau hub-spoke avec MCP

Utilisez cette requête avec MCP actif pour générer une topologie hub-and-spoke complète :

Generate a Bicep template for a hub-spoke VNet topology:
- Hub VNet: 10.0.0.0/16 with AzureFirewallSubnet (/26) and GatewaySubnet (/27)
- Spoke VNet: 10.1.0.0/16 with an application subnet (/24)
- VNet peering between hub and spoke (both directions)
- Azure Firewall Standard tier in the hub
- Azure Firewall Policy linked to the firewall
- Public IP for the firewall
- NSG on the application subnet blocking inbound SSH and RDP from internet
- Log Analytics Workspace for diagnostic logging
- Diagnostic settings on the firewall sending logs to the workspace
Parameters: location, environment, owner, costCenter
Use latest stable API versions.

Avec MCP actif, Copilot utilise les versions actuelles de l’API, lie correctement le firewallPolicy à la ressource AzureFirewall, génère la ressource diagnosticSettings avec le bon logs et le bon format de tableau metrics, et utilise dependsOn uniquement lorsque les références symboliques ne suffisent pas.

Validation et bonnes pratiques

Toujours exécuter az bicep build

Après chaque génération de Copilot, exécutez :

az bicep build --file main.bicep

Cette commande compile Bicep pour Azure Resource Manager JSON et intercepte les erreurs de syntaxe, les propriétés requises manquantes et les références non valides. Il s’agit d’une étape de validation rapide qui intercepte de nombreux problèmes avant le déploiement.

Utiliser what-if avant chaque déploiement

La commande what-if affiche exactement ce que Azure crée, modifie ou supprime, sans apporter de modifications :

az deployment group what-if \
  --resource-group rg-iaclab \
  --template-file main.bicep \
  --parameters @params.json

Vérifiez le résultat avant chaque déploiement. Recherchez les ressources supprimées que vous n’avez pas l’intention de supprimer, les modifications qui semblent inattendues et un nombre de ressources correspondant à votre conception.

Utiliser des fichiers de paramètres pour des valeurs spécifiques à l’environnement

Copilot pouvez générer des fichiers de paramètres à partir de vos modèles :

Generate a Bicep parameters file (bicepparam format) for the template above.
Create values appropriate for a staging environment.
Include comments explaining what each parameter controls.

Ce type de prompt génère un fichier .bicepparam que vous pouvez placer sous contrôle de version avec le template, avec un fichier pour chaque environnement.

Demandez à Copilot de documenter sa réponse

Add @description() decorators to every parameter and output in this template.
The descriptions should be clear enough for someone who has never seen the template
to understand what each parameter controls and what constraints apply.

Cet exemple de prompt rend le modèle autodocumenté et améliore la sortie what-if, qui affiche les descriptions des paramètres.

Résolution des problèmes courants liés à Copilot

Référence de ressource non valide

Symptôme : bicep build échoue avec "The referenced resource could not be found."

This Bicep template has an invalid resource reference at line [X].
The resource [name] references [other resource] but uses a hardcoded string
instead of the symbolic name. Fix all cross-resource references to use
symbolic names.

Dépendance circulaire

Symptôme : bicep build échoue avec "A cycle was detected in the template."

This Bicep template has a circular dependency between [resource A] and
[resource B]. Restructure the template to break the cycle. One approach
is to use an existing() reference for one of the resources.

Version obsolète de l’API

Symptôme : Le déploiement échoue avec "The resource type [X] was not found in the namespace."

The resource type [Microsoft.Network/azureFirewalls@2021-02-01] appears to
use an outdated API version. Update it to the current stable API version
and adjust any properties that have changed.