Présentation

  • 8 minutes

L’infrastructure en tant que code (IaC) est la pratique de la définition et de la gestion des ressources cloud via des fichiers de configuration lisibles par l’ordinateur plutôt que par le biais de scripts sélectionnés ou non planifiés dans le portail manuel. Au lieu de vous connecter au portail Azure pour créer un réseau virtuel, vous écrivez un fichier qui décrit le réseau. Un outil lit ensuite ce fichier et crée la ressource pour vous.

Cette approche apporte un changement fondamental dans la façon dont l’infrastructure est gérée. Les modifications sont suivies dans le contrôle de version, les déploiements sont reproductibles et les environnements peuvent être recréés à partir de zéro à tout moment. En cas de problème, il est possible de restaurer un état antérieur. Si vous avez besoin d’un environnement intermédiaire qui met en miroir la production, vous appliquez les mêmes fichiers avec différents paramètres.

IaC intègre également l’infrastructure dans la même discipline d’ingénierie que le code d’application. Les mêmes flux de travail de pull request, les révisions de code et les pratiques de test automatisées qui s’appliquent à votre application peuvent désormais s’appliquer aux systèmes sur lesquels votre application s’exécute.

En l'absence d'assistance de l'IA, le cycle de création d'Infrastructure sous forme de Code (IaC) se présente ainsi :

  1. Écrire un modèle
  2. Rechercher la documentation
  3. Correction de la syntaxe
  4. Valider localement
  5. Lancer une simulation
  6. Déployer vers un environnement intermédiaire
  7. Examiner les modifications
  8. Déployer en production

Répétez la même opération pour chaque déploiement, qu’il s’agisse de nouveautés ou de mises à jour.

Objectifs d’apprentissage

À la fin de ce module, vous pouvez :

  • Expliquer l’infrastructure en tant que code et pourquoi elle est importante dans les opérations cloud modernes
  • Décrire la différence entre les approches déclaratives et impératives de l’IaC
  • Identifier le flux de travail de création IaC traditionnel et ses points de friction
  • Expliquer comment GitHub Copilot modifie la boucle interne IaC
  • Décrire les fonctionnalités GitHub Copilot les plus pertinentes pour le travail d’infrastructure

Défis liés à l’infrastructure en tant que code

Chaque étape a des frictions. L’écriture d’un modèle Bicep à partir de zéro nécessite une connaissance des types de ressources, des versions d’API, des propriétés requises et des conventions d’affectation de noms spécifiques à Azure. La recherche de la version correcte de l’API pour Microsoft.Network/virtualNetworks signifie naviguer dans la documentation ou copier à partir de projets précédents. Les erreurs de syntaxe sont interceptées après l’exécution d’une commande de build. Et maintenir les modèles à jour à mesure que Azure API évoluent, est une charge de maintenance continue.

Le résultat est que l’IaC est souvent traitée comme une compétence spécialisée. Les ingénieurs qui ne rédigent pas régulièrement de modèles reviennent à une sélection via le portail, ce qui compromet la cohérence que l’IaC est censée garantir.

Approche déclarative et impérative

Il existe deux styles fondamentaux d’IaC. Comprendre la différence vous aide à choisir le bon outil et à créer de meilleurs prompts pour GitHub Copilot.

Outil IaC déclaratif

Dans une approche déclarative, vous décrivez l’état final souhaité de votre infrastructure. L’outil explique comment y arriver.

« Je veux un réseau virtuel avec un espace d’adressage 10.0.0.0/16 et deux sous-réseaux. »

Azure Bicep et les modèles ARM sont déclaratifs. Vous définissez les ressources qui doivent exister et Azure Resource Manager gère le séquencement et la création. Si la ressource existe déjà dans l’état correct, aucune modification n’est appliquée. S’il n’existe pas, il est créé. S’il est différent, il est mis à jour.

Outil IaC impératif

Dans une approche impérative, vous décrivez les étapes nécessaires pour atteindre l’état souhaité. Vous écrivez une procédure, pas une déclaration.

« Vérifiez si le réseau virtuel existe. Si ce n’est pas le cas, exécutez az network vnet create...."

Azure CLI et les scripts Azure PowerShell sont généralement impératifs. Vous contrôlez le flux, gérez les erreurs et gérez le classement vous-même. En vous donnant plus de contrôle, mais aussi plus de responsabilité. Cela inclut la gestion de l’idempotency, ce qui signifie que le script doit être sécurisé pour s’exécuter plusieurs fois.

Laquelle devez-vous utiliser ?

Le bon choix dépend du scénario. Les outils déclaratifs tels que Bicep sont mieux adaptés à la gestion des ressources d’infrastructure de longue durée, car ils gèrent automatiquement l’état et la dérive. Les outils impératifs tels que les scripts CLI sont meilleurs pour les tâches opérationnelles, les étapes de configuration ponctuelles ou l’automatisation qui implique la logique, les conditions et les boucles.

Dans la pratique, la plupart des ingénieurs cloud utilisent les deux. Et GitHub Copilot aide aussi avec les deux.

Comment GitHub Copilot modifie le processus de création de modèle

GitHub Copilot raccourcit et simplifie chaque étape du cycle de création IaC.

À l'étape de rédaction, Copilot génère des définitions de ressources complètes à partir des descriptions du langage naturel. Au lieu de rechercher la syntaxe Bicep pour une ressource Azure, vous décrivez ce dont vous avez besoin et Copilot produit un point de départ en secondes.

At the review stage, Copilot peut analyser un modèle existant et identifier les lacunes de sécurité, les propriétés manquantes ou les modèles obsolètes. Il agit comme un deuxième ensemble d’yeux avant le déploiement du modèle.

At l’étape de transformation, Copilot pouvez convertir entre Azure CLI et PowerShell, entre Azure Resource Manager JSON et Bicep, ou entre Azure Pipelines et GitHub Actions. Réduction du coût de changement d’outils ou adaptation d’exemples à partir de la documentation.

At la phase de documentation, Copilot peut lire un modèle terminé et générer des explications lisibles par l’homme, des références de paramètres et des descriptions d’architecture. Travail souvent ignoré entièrement parce qu’il est fastidieux de le faire manuellement.

Le décalage ne concerne pas seulement la vitesse. Il s’agit de réduire la barrière à l’entrée. Les ingénieurs qui ne sont pas spécialistes de Bicep peuvent maintenant produire des modèles corrects et bien structurés en décrivant leur intention en langage simple.

fonctionnalités de GitHub Copilot pour le travail d’infrastructure

GitHub Copilot s’intègre à VS Code de plusieurs manières, chacune étant adaptée à différentes étapes du workflow IaC.

Suggestions en ligne

Lorsque vous tapez un fichier .bicep, .yaml, .ps1 ou .sh, Copilot offre des achèvements en temps réel. Si vous tapez le début d’une définition de ressource, Copilot prédit le reste. Y compris les propriétés requises, les valeurs par défaut et les modèles courants. Vous acceptez avec Tab ou ignorez avec Escape.

Les suggestions inline fonctionnent mieux pour les modèles continus, déjà établis dans le fichier. Si vous définissez correctement une ressource, Copilot comprend la structure et suggère des ressources similaires selon le même style.

Copilot Chat

Copilot conversation (Ctrl+Alt+I) est une interface de conversation où vous pouvez poser des questions, décrire ce que vous souhaitez créer, coller du code existant pour la révision ou demander des explications.

La conversation est meilleure que les suggestions inline pour les tâches qui nécessitent plus de contexte. Exemples tels que la génération d’un modèle entier à partir de zéro, la refactorisation d’un fichier complexe ou la demande d’explication du fonctionnement d’une ressource.

Copilot avec MCP (Model Context Protocol)

MCP permet Copilot de se connecter à des outils et sources de données externes. Le serveur MCP Bicep donne Copilot accès aux définitions de type Bicep dynamiques, aux versions actuelles de l’API et aux règles de validation. Ce qui rend sa sortie Bicep plus précise que celle qu’il peut générer à partir des seules données d’entraînement.

Pourquoi l’IaC est bien adaptée à l’assistance de l’IA

Les définitions d’infrastructure ont des qualités qui leur font de bons candidats pour la génération assistée par l’IA :

  • Elles sont hautement structurées : les définitions de ressources suivent des schémas. Les propriétés sont basées sur des types connus, des valeurs valides et des désignations obligatoires/facultatives. Cette nature structurée facilite la production d’une sortie syntactiquement correcte pour un modèle.
  • They sont riches en modèles : la plupart des déploiements Azure utilisent un ensemble relativement petit de types de ressources courants : réseaux virtuels, comptes de stockage, ressources de calcul et identité. Ces modèles apparaissent fréquemment dans les données d’apprentissage, ce qui signifie Copilot repose sur de nombreux exemples.
  • Ils sont coûteux à rechercher manuellement : la recherche de la combinaison correcte de la version de l’API, des propriétés requises et des références SKU valides pour un type de ressource inconnu peut prendre beaucoup de temps. Copilot synthétise ces recherches sous la forme d’une requête.
  • Ils permettent une itération en toute sécurité : vous validez avant de déployer. Une suggestion incorrecte de Copilot est interceptée à az bicep build ou what-if avant de toucher les ressources réelles. Ce filet de sécurité encourage l’expérimentation.

Points importants à retenir

  • IaC traite l’infrastructure en tant que code : contrôle de version, reproductible et révisable.
  • Les outils déclaratifs comme Bicep décrivent l’état final souhaité ; les outils impératifs tels que l’interface CLI décrivent les étapes à suivre.
  • Le flux de travail IaC traditionnel présente des frictions importantes à chaque étape. Copilot réduit cette friction.
  • GitHub Copilot aide à travers des suggestions en ligne, du Copilot Chat et un contexte amélioré par MCP.
  • IaC est bien adapté à l’assistance de l’IA, car elle est structurée, riche en modèles et sécurisée pour itérer.

Note

Nous reconnaissons que différentes personnes aiment apprendre de différentes façons. Vous pouvez choisir d’effectuer ce module au format vidéo ou lire le contenu sous forme de texte et d’images. Le texte contient plus de détails que les vidéos. Dans certains cas, vous voudrez peut-être y faire référence en tant que matériel supplémentaire à la présentation vidéo.