Ingénierie rapide pour l’infrastructure en tant que code
Tip
Pour plus d’informations, consultez l’onglet Texte et images !
GitHub Copilot est aussi utile que les instructions que vous lui donnez. Pour les tâches d’infrastructure, une invite vague produit un modèle générique qui peut ne pas correspondre à vos conventions d’affectation de noms, normes de sécurité ou modèles architecturaux. Une requête soigneusement formulée produit un résultat proche d’une implémentation prête pour la production.
Ce n’est pas une différence mineure. Une invite telle que create a Bicep template for a Réseau virtuel peut produire un exemple minimal sans sous-réseaux, aucune étiquette et une région codée en dur. Une requête semblable à celle que vous rédigerez à la fin de cette unité pourrait générer un réseau virtuel entièrement paramétré, balisé et composé de plusieurs sous-réseaux, avec des associations NSG et des paramètres de diagnostic. Structure correcte et prête à être validée.
La compétence d'écrire de bonnes incitations peut être apprise. Cette unité couvre les techniques qui produisent constamment une meilleure sortie d’infrastructure à partir de GitHub Copilot.
Anatomie d’une invite IaC efficace
Toute requête d’infrastructure efficace combine quatre éléments essentiels :
Contexte
Le contexte indique Copilot quel type de travail vous effectuez et quelles contraintes s'appliquent. Sans contexte, Copilot fait des hypothèses. Ces hypothèses peuvent ne pas correspondre à votre environnement.
Exemple de requête moins efficace : « Créez un compte de stockage dans Bicep. »
« Prompt optimisé » : « Créer une définition de ressource Bicep pour un compte de stockage Azure. » Déploiement dans un environnement de production situé dans la région Australie Est. Le compte doit utiliser Standard_LRS et exiger un accès HTTPS uniquement. »
Le contexte inclut l’environnement cible (développement/préproduction/production), la région, l’outil ou le langage, les contraintes existantes (conventions d’affectation de noms, stratégies de balisage) et les normes que vous souhaitez respecter.
Exigences
Les exigences sont les fonctionnalités, propriétés ou comportements spécifiques dont la ressource doit avoir. Être explicite sur les exigences empêche Copilot d'omettre les éléments qu'il ne peut pas déduire.
Par exemple:
The storage account must: have soft delete enabled for blobs (7 days), use a private endpoint, disable public blob access, and be tagged with Environment, Owner, and CostCenter.
Répertoriez les exigences sous forme de listes à puces ou d'éléments numérotés lorsque vous en avez plusieurs. Copilot gère bien les listes structurées et est moins susceptible d’ignorer les éléments.
Format de sortie
Indiquez Copilot quel type de sortie vous attendez. Pour IaC, cela signifie généralement spécifier le langage ou l’outil, que vous souhaitiez un fichier complet ou simplement un extrait de code, et comment les paramètres doivent être gérés.
Par exemple:
Output a complete Bicep file with parameters at the top, a resource block in the middle, and outputs at the bottom. Use decorators to add descriptions to all parameters.
Si vous ne spécifiez pas de format, Copilot en choisit un. Il peut choisir des valeurs codées en dur inline lorsque vous souhaitez des paramètres ou un extrait de code lorsque vous souhaitez un fichier complet.
Constraints
Les contraintes indiquent Copilot quoi éviter. Facile à ignorer, mais important, en particulier pour la sécurité ou la conformité.
Par exemple:
Do not use any deprecated API versions. Do not expose any management ports (22, 3389) in NSG rules. Do not hardcode any subscription IDs or tenant IDs.
Requête « zero-shot »
Une requête « zero-shot » consiste à décrire ce que vous souhaitez obtenir sans fournir d’exemples. Il s'agit de l'approche la plus courante et fonctionne bien pour les modèles d'infrastructure standard, en fonction des données entraînées par Copilot.
Par exemple:
Generate a Bicep template for an Azure Key Vault with the following requirements:
- SKU: Standard
- Soft delete enabled with a 90-day retention period
- Purge protection enabled
- RBAC authorization model (not access policies)
- Public network access disabled
- A private endpoint connected to a subnet parameter
- Tags: Environment, Owner, CostCenter (all as parameters)
Use descriptive parameter names and add @description() decorators to each.
Zero-shot fonctionne mieux lorsque le type de ressource est courant et que vos exigences sont spécifiques. Si vous utilisez un type de ressource moins courant ou si vous avez besoin d’une structure particulière, envisagez de fournir un exemple.
Requête « few-shot »
Une requête « few-shot » consiste à fournir un ou plusieurs exemples dans la requête afin que Copilot comprenne le modèle ou le style attendu. Utile lorsque vous disposez d'une base de code existante avec des conventions dont Copilot ne serait pas informé autrement.
Voici un exemple de ce à quoi pourrait ressembler une requête « few-shot » :
Here is an example of how we define storage accounts in our Bicep codebase:
[paste your existing storage account resource block]
Using the same naming convention, parameter style, and tag structure, generate
a similar resource block for an Azure Service Bus namespace with these requirements:
- Standard SKU
- Geo-redundant disaster recovery enabled
- Minimum TLS 1.2
- Same tagging pattern as the example
En montrant Copilot votre modèle existant, vous obtenez une sortie qui se fusionne dans votre base de code plutôt que la sortie qui suit le style par défaut de Copilot. Gagner du temps de nettoyage important lors de l’intégration du code généré avec des modèles existants.
Invite basée sur les rôles
La sollicitation basée sur les rôles demande à Copilot d’adopter une perspective spécifique avant de produire le résultat. Il est efficace pour les révisions de sécurité et les conseils architecturaux.
Voici un exemple dans le contexte de sécurité :
You are a senior Azure security engineer reviewing Bicep templates for enterprise
production deployments. Review the following template and identify:
- Any security misconfigurations or missing security controls
- Resources that expose public endpoints unnecessarily
- Missing diagnostic settings or logging configuration
- RBAC assignments that are too broad
- Any deprecated API versions
For each issue found, explain the risk and provide the corrected Bicep snippet.
Les requêtes fondées sur les rôles font évoluer le résultat de Copilot de « voici un code fonctionnel » vers « voici un code fonctionnel, sécurisé et conforme au principe du moindre privilège ». L’écart de qualité est significatif.
Affinement itératif
La manière la plus efficace de collaborer avec GitHub Copilot sur des tâches d’Infrastructure as Code ne consiste pas à rédiger une unique requête parfaite. Elle consiste plutôt à commencer avec une approche générale puis à affiner progressivement le résultat.
Un exemple de processus de développement passerait par les étapes suivantes :
Étape 1 : Démarrer avec la ressource principale
Generate a Bicep template for a hub-spoke VNet topology with one hub and one spoke.
Passez en revue le résultat. La structure de base est-elle correcte ? Les espaces d’adressage sont-ils sensibles ?
Étape 2 : Ajouter des exigences de sécurité
Add an NSG to the application subnet in the spoke that blocks all inbound
internet traffic except HTTPS (port 443). Add a deny-all rule at the end.
Étape 3 : Ajouter une observabilité
Add diagnostic settings to the NSG that send flow logs to a Log Analytics
workspace. Add the Log Analytics workspace as a new parameter.
Étape 4 : Ajouter un paramétrage
Replace all hardcoded values (address spaces, location, resource names)
with parameters. Add @description() and @allowed() decorators where appropriate.
Étape 5 : Ajouter des balises
Add tag parameters for Environment, Owner, and CostCenter. Apply tags to
every resource in the template using a tags object parameter.
Cette approche en cinq étapes produit constamment une meilleure sortie qu’une invite complexe unique, car chaque étape s’appuie sur une sortie validée de la précédente. Vous passez en revue et acceptez chaque incrément avant d’ajouter la couche suivante des exigences.
Erreurs d’invite courantes
Être trop vague
Problème : en utilisant une invite comme Create a Bicep template for my infrastructure
Résultat: Modèle minimal avec des valeurs devinées, des types de ressources incorrects et aucun paramètre de sécurité.
Correctif: Soyez spécifique sur les ressources dont vous avez besoin, quelles références SKU, quelles régions et quelles exigences de sécurité s’appliquent.
Oubli des contraintes de sécurité
Problème: Génération d’un modèle de machine virtuelle sans spécifier que les ports de gestion ne doivent pas être ouverts
Résultat : un groupe de sécurité (NSG) qui autorise les connexions SSH et RDP entrantes depuis Internet. Il s’agit d’une grave erreur de configuration de sécurité
Correction: Indiquez explicitement les exigences de sécurité pour chaque invite d’infrastructure. Ne supposez pas que Copilot est par défaut sécurisé.
Ne pas spécifier les préférences de version de l’API
Problème : en utilisant une invite comme Use the latest API version
Result : Sans MCP, Copilot peut toujours utiliser des versions de ses données d’apprentissage, qui peuvent être obsolètes.
Fix : Activez le serveur MCP Bicep ou indiquez explicitement la version de l’API si elle est connue. Au minimum, demandez à Copilot d'indiquer s'il n'est pas certain de la version de l'API.
Demander trop dans une invite
Problème : une commande de 20 lignes demandant une zone d’atterrissage Azure complète, comprenant la mise en réseau, l'identité, la gouvernance et la surveillance. Tout à la fois.
Résultat : Un modèle long avec de nombreuses lacunes, des références croisées entre ressources manquantes, et des propriétés devinées par Copilot.
Correction: Utilisez l’affinement itératif. Générez le modèle dans des couches et validez chaque couche avant d’ajouter la suivante.
Ne pas fournir de contexte pour les bases de code existantes
Problème : Demander à Copilot de add a subnet to the Réseau virtuel sans partager la définition de la ressource Réseau Virtuel existante.
Résultat: Nouvelle ressource de sous-réseau qui peut entrer en conflit avec la structure ou le nommage de la définition existante.
Correctif: Collez toujours le code existant pertinent dans l’invite lorsque vous étendez ou modifiez les modèles existants.
Modèles d’invite pour l’infrastructure
Les modèles suivants s’appliquent directement aux tâches de ce module.
Modèle de génération
Utilisez-le lors du démarrage à partir de zéro :
Generate a [tool: Bicep/CLI/YAML] [resource type] with the following requirements:
- [requirement 1]
- [requirement 2]
- [requirement 3]
Parameterize: [list of values to parameterize]
Tag every resource with: [tag names]
Do not: [constraints]
Modèle d’extension
Utilisez cette fonction lors de l’ajout à un modèle existant :
Given this existing [tool] [resource definition]:
[paste existing code]
Add the following:
- [addition 1]
- [addition 2]
Maintain the existing naming convention and parameter style.
Modèle de révision
Utiliser lors de l’audit d’un modèle existant :
Review this [tool] template for:
- Security misconfigurations
- Missing required properties
- Deprecated API versions
- Resources exposed to the public internet unnecessarily
- Missing tags or diagnostic settings
For each issue, explain the problem and provide the corrected snippet.
[paste template]
Modèle de traduction
Utiliser lors de la conversion entre les outils :
Translate this [source tool] [script/template/pipeline] to [target tool].
Preserve:
- The same variable/parameter names where possible
- Error handling logic
- The same resource naming and tagging
Do not add features that are not in the original.
[paste source code]
Modèle d’explication
Utilisez quand vous devez comprendre l’infrastructure existante :
Explain what this [tool] template deploys in plain language.
Describe each resource, its purpose, and how the resources relate to each other.
Identify any security controls that are configured.
Highlight anything that looks unusual or that might cause problems in production.
[paste template]
L’état d’esprit de révision
GitHub Copilot est un collaborateur, pas une autorité. Chaque sortie produite doit être examinée avant d’utiliser. En particulier pour l’infrastructure, où une configuration incorrecte peut exposer des systèmes à Internet, verrouiller des ressources ou entraîner des coûts inattendus.
Les questions à poser lors de l'examen de la sortie de l'infrastructure de Copilot :
- La version de l’API est-elle actuelle ? Vérifiez la documentation Azure ou utilisez Bicep MCP.
- Toutes les propriétés requises sont-elles présentes ? Exécutez
az bicep buildpour intercepter les champs obligatoires manquants. - Les paramètres de sécurité par défaut sont-ils appropriés ? Vérifiez l’accès au réseau public, l’exposition des ports de gestion et les paramètres de chiffrement.
- Les ressources sont-elles correctement référencées ? Vérifiez que les noms symboliques, et non les ID codés en dur, sont utilisés pour les références de ressources.
- Est-ce idempotent ? L’exécution de ce modèle créerait-elle deux fois des conflits ou des doublons ?
Le traitement de la sortie de Copilot comme un premier brouillon, pas une réponse finale, est l'état d'esprit qui produit les meilleurs résultats.
Points importants à retenir
- Les invites IaC effectives incluent le contexte, les exigences, le format de sortie et les contraintes.
- L’approche « zero-shot » fonctionne bien pour les types de ressources courants ; l’approche « few-shot » est plus efficace lorsque vous disposez déjà de modèles de code existants auxquels vous souhaitez vous conformer.
- Incitation basée sur les rôles (« Vous êtes un ingénieur de sécurité Azure senior... ») améliorent la qualité des révisions et des conseils architecturaux.
- L’affinement itératif, construit par couches successives, produit un résultat de meilleure qualité qu’une seule requête massive.
- Passez toujours en revue la sortie de Copilot avant de l'utiliser : vérifiez les versions de l'API, les propriétés requises, les paramètres de sécurité et les références de ressources.