Convertir et migrer vos ressources vers un fichier Bicep

Effectué

Quand vous démarrez le processus de migration vers Bicep, il est important de suivre un processus structuré pour garantir que votre fichier Bicep décrit correctement vos ressources Azure. Vous devez vérifier que votre code Bicep suit les meilleures pratiques, et qu’il est entièrement testé et sécurisé afin de pouvoir l’utiliser pour les déploiements suivants. Dans cette unité, vous découvrez les deux premières phases de votre migration Bicep : la phase de conversion et la phase de migration.

L’objectif principal de ces deux phases est de préparer un nouveau fichier Bicep avant de le refactoriser et de le tester ultérieurement.

Phase de conversion

L’objectif de la phase de Conversion de la migration de vos ressources vers Bicep est de capturer une représentation initiale de vos ressources Azure. Le fichier Bicep que vous créez dans cette phase n’est pas complet et il n’est pas prêt pour une utilisation. Le fichier vous donne cependant un point de départ pour votre migration.

La phase de conversion se compose de deux étapes possibles, que vous effectuez dans l’ordre :

1. Capturez une représentation de vos ressources Azure.
2. Si nécessaire, convertissez la représentation JSON en Bicep en utilisant la commande decompile.

Si vous avez un modèle JSON existant que vous convertissez en Bicep, la première étape est simple parce que vous avez déjà votre modèle source. Vous allez découvrir comment la décompiler en Bicep dans cette unité.

Si vous convertissez des ressources Azure qui ont été déployées en utilisant le portail Azure ou un autre outil, vous devez capturer les définitions des ressources. Vous pouvez exporter les définitions des ressources et les convertir en Bicep, ou bien vous pouvez utiliser la commande Insérer une ressource dans Visual Studio Code pour insérer une représentation Bicep de votre ressource Azure.

Comment Azure représente les ressources

Azure Resource Manager est le service utilisé pour déployer et gérer des ressources dans Azure. Toutes les ressources déployées sur Azure sont suivies par Resource Manager, quelle que soit la méthode qui a été utilisée pour déployer la ressource. Vous pouvez utiliser le portail Azure, Azure CLI, Azure PowerShell, l’API REST de Resource Manager et les SDK Azure pour interagir avec Resource Manager.

Il existe deux types d’opérations dans Azure : les opérations de plan de contrôle et les opérations de plan de données. Les opérations de plan de contrôle sont utilisées pour gérer les ressources de votre abonnement. Les opérations de plan de données sont utilisées pour accéder aux fonctionnalités exposées par une ressource. Par exemple, vous utilisez une opération de plan de contrôle pour créer une machine virtuelle, mais vous utilisez une opération de plan de données pour vous connecter à la machine virtuelle à l’aide du protocole RDP (Remote Desktop Protocol).

Exporter des ressources existantes vers un modèle JSON

Quelle que soit la façon dont vos ressources Azure sont créées, Resource Manager rend les informations sur chaque ressource disponibles au format JSON. Quand vous demandez une copie de la représentation JSON d’une ressource, vous exportez la ressource. Le fichier JSON que vous exportez peut être décompilé dans Bicep.

Resource Manager fournit plusieurs moyens d’exporter des ressources Azure vers un modèle. Vous pouvez utiliser le portail Azure, Azure CLI et les applets de commande Azure PowerShell pour exporter des ressources individuelles, plusieurs ressources et des groupes de ressources entiers.

Le processus d’exportation est une opération de plan de contrôle, ce qui signifie qu’il exporte seulement la configuration des ressources Azure. Par exemple, quand vous exportez une machine virtuelle, les données présentes sur le disque dur d’une machine virtuelle ne sont pas exportées. Et quand vous exportez un compte de stockage, les objets blob et autres contenus du compte de stockage ne sont pas inclus dans le processus d’exportation.

Vous devez tenir compte de quelques aspects lorsque vous exportez des ressources existantes :

• La définition d’une ressource exportée est un instantané de l’état actuel de cette ressource. Elle comprend toutes les modifications apportées à la ressource depuis son déploiement initial.
• Le modèle exporté peut inclure des propriétés de ressource par défaut qui sont normalement omises dans une définition Bicep. Par exemple, le processus d’exportation peut ajouter des propriétés en lecture seule qu’Azure définit automatiquement. Cela n’a aucun intérêt d’inclure ces propriétés parce qu’elles sont en lecture seule. Envisagez de supprimer ces propriétés des définitions de ressources quand vous migrez vers Bicep, afin d’éviter du code inutile dans les fichiers Bicep qui pourrait entraîner de la confusion.
• Le modèle exporté n’inclura probablement pas tous les paramètres dont vous aurez besoin pour rendre le modèle réutilisable. Quand vous exportez un modèle, la plupart des propriétés sont codées en dur dans le modèle. Vous allez voir comment ajouter des paramètres plus loin dans ce module.
• Certaines ressources ne peuvent pas être exportées en utilisant cette approche, et vous devez les définir manuellement dans votre fichier Bicep. Vous allez apprendre à recréer ces ressources plus loin dans cette unité.

Enregistrer des déploiements dans un modèle JSON

Si vous avez déjà déployé une ressource manuellement à partir du portail Azure, vous avez sans doute remarqué la possibilité de Télécharger un modèle pour l’automatisation dans le volet Vérifier + créer. Cette option enregistre un modèle ARM JSON qui est basé sur les noms et les propriétés que vous avez définis lors de la création de la ressource dans le portail.

Resource Manager effectue également le suivi des déploiements des ressources. Les opérations de déploiement incluent les modifications soumises par l’expérience de création des ressources du portail Azure ainsi que les déploiements de modèles ARM. Les modifications apportées aux ressources existantes en utilisant le portail Azure, les applets de commande Azure PowerShell, Azure CLI ou d’autres outils ne créent généralement pas de déploiements.

Si les déploiements ont été créés en utilisant un outil compatible, vous pouvez accéder au modèle de déploiement à partir de l’historique de déploiement du groupe de ressources. Vous pouvez utiliser le portail Azure, Azure CLI ou Azure PowerShell pour enregistrer les déploiements.

Vous devez tenir compte de quelques aspects lorsque vous enregistrez vos modèles à l’aide de cette méthode :

• Le modèle enregistré montre l’état des ressources au moment du déploiement. Elle n’inclut pas les modifications qui ont été apportées après le déploiement.
• Si le déploiement contenait plusieurs ressources, vous ne pouvez pas sélectionner des ressources spécifiques à inclure et à exclure. Cette opération télécharge la définition de toutes les ressources qui faisaient partie du déploiement initial. Cependant, quand vous passez à la phase de migration du processus, vous pouvez ignorer manuellement les ressources dont vous n’avez pas besoin.
• Le modèle inclut seulement les propriétés de ressource qui sont nécessaires au déploiement.
• Le modèle peut inclure des paramètres que vous pouvez utiliser pour redéployer le modèle dans plusieurs environnements. Cependant, vous devez vérifier que ces paramètres répondent à vos besoins.
• Le modèle n’inclut probablement pas de propriétés superflues, mais vous devez toujours vérifier que le modèle inclut tout ce que vous attendez et supprimer toute propriété inutile.

Notes

Quelle que soit la façon dont vous exportez des ressources, en exportant des ressources existantes ou en enregistrant des déploiements, traitez le fichier exporté comme un point de départ et ne l’utilisez pas directement. Utilisez-le plutôt comme un point de départ pour votre modèle final.

Insérer des ressources existantes dans Bicep

L’extension Bicep pour Visual Studio Code comprend la commande Insérer une ressource, qui capture une représentation Bicep d’une ressource Azure. Cette commande lit la définition JSON de la ressource à partir d’Azure, supprime les propriétés qui sont reconnues en lecture seule et décompile JSON en Bicep. À l’instar de la fonction d’exportation, le code Bicep résultant peut être utilisé comme point de départ pour votre fichier Bicep final.

Vous pouvez insérer une ressource en ouvrant la palette de commandes Visual Studio Code. Utilisez Ctrl + Maj + P sur Windows et Linux et ⌘ + Maj + P sur macOS.

Décompiler le modèle ARM JSON source

La deuxième étape de la migration de vos ressources Azure vers Bicep consiste à convertir vos modèles ARM JSON et vos ressources Azure en modèles Bicep. Les outils Bicep incluent la commande decompile pour convertir des modèles. Vous pouvez appeler la commande decompile à partir d’Azure CLI ou de l’interface CLI de Bicep.

Le processus de décompilation ne garantit pas un mappage complet de JSON à Bicep. Vous devrez probablement revoir le fichier Bicep généré pour répondre aux bonnes pratiques de votre modèle avant d’utiliser le fichier pour déployer des ressources. Considérez-le comme point de départ de votre migration. Plus loin dans ce module, vous découvrez comment résoudre les problèmes que vous rencontrez dans le processus de décompilation.

Une fois que vous avez décompilé votre modèle, vous avez terminé la phase de conversion. Vous avez maintenant un fichier Bicep valide avec lequel vous pouvez démarrer.

Phase de migration

L’objectif de la phase Migration de la migration de vos ressources vers Bicep est de créer la première ébauche de votre fichier Bicep déployable et de vérifier qu’il définit toutes les ressources Azure qui sont dans l’étendue de la migration.

La phase de migration se compose de trois étapes, que vous effectuez dans l’ordre :

1. Créer un fichier Bicep vide.
2. Copier chaque ressource depuis votre modèle décompilé.
3. Identifier et recréer les ressources manquantes.

Créer un fichier Bicep

Une bonne pratique consiste à créer un nouveau fichier Bicep. Le fichier que vous avez créé dans la phase de conversion est un point de référence que vous pouvez examiner, mais vous ne devez pas le considérer comme final ou le déployer en l’état.

Copier des ressources dans le nouveau fichier Bicep

Copiez chaque ressource individuellement depuis le fichier Bicep converti vers le nouveau fichier Bicep. Ce processus vous aide à résoudre les éventuels problèmes de chaque ressource et à éviter toute confusion au fur et à mesure que la taille de votre modèle augmente.

Recréer les ressources non prises en charge

Tous les types de ressources Azure ne peuvent pas être exportés via le portail Azure, Azure CLI ou Azure PowerShell. Par exemple, des extensions de machine virtuelle comme DependencyAgentWindows et MMAExtension (Microsoft Monitoring Agent) sont des types de ressources que vous ne pouvez pas exporter.

Quand vous tentez d’exporter une ressource en utilisant le portail Azure, Azure CLI ou Azure PowerShell et qu’un type de ressource non pris en charge est inclus, un message d’erreur détaillé est généré. Vous devez recréer les ressources qui n’ont pas été exportées, comme les extensions de machine virtuelle, dans votre nouveau fichier Bicep. Vous pouvez choisir entre plusieurs outils et approches pour recréer les ressources, notamment Azure Resource Explorer, les informations de référence des modèles ARM et les modèles de démarrage rapide Azure.

Azure Resource Explorer

Azure Resource Explorer est un outil incorporé dans le portail Azure. Le portail ne montre pas certains types de ressources, mais Resource Explorer vous donne une représentation JSON de vos ressources. Pour accéder à Resource Explorer, recherchez-le dans la zone de recherche :

Le volet des résultats montre une liste des fournisseurs de ressources inscrits dans votre abonnement et les détails de l’ensemble des ressources, groupes de ressources et abonnements que vous avez l’autorisation de voir. Pour afficher une représentation JSON d’une ressource, sélectionnez la hiérarchie sur le côté gauche du volet :

En sélectionnant une ressource, vous pouvez voir la représentation JSON, comme dans cet exemple :

{
    "name": "DependencyAgentWindows",
    "id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/rg-app-prod-truckline/providers/Microsoft.Compute/virtualMachines/vm-prod-001/extensions/DependencyAgentWindows",
    "type": "Microsoft.Compute/virtualMachines/extensions",
    "location": "eastus",
    "properties": {
        "autoUpgradeMinorVersion": true,
        "provisioningState": "Succeeded",
        "publisher": "Microsoft.Azure.Monitoring.DependencyAgent",
        "type": "DependencyAgentWindows",
        "typeHandlerVersion": "9.10"
    }
}

Vous pouvez utiliser la représentation JSON pour définir une ressource Bicep :

resource dependencyAgentWindows 'Microsoft.Compute/virtualMachines/extensions@2022-08-01' = {
  parent: virtualMachine
  name: 'DependencyAgentWindows'
  location: 'eastus'
  properties: {
    autoUpgradeMinorVersion: true
    publisher: 'Microsoft.Azure.Monitoring.DependencyAgent'
    type: 'DependencyAgentWindows'
    typeHandlerVersion: '9.10'
  }
}

Notes

La représentation JSON comprend une propriété nommée provisioningState. La propriété provisioningState est en lecture seule et automatiquement définie par Azure, donc elle n’est pas incluse dans la définition de ressource Bicep.

Conseil

L’extension Bicep pour Visual Studio Code vous permet de définir vos ressources Azure dans Bicep. Par exemple, la représentation Bicep de la ressource comprend une version de l’API, contrairement à la version JSON exportée. Dans Visual Studio Code, lorsque vous commencez à entrer le type de ressource, une version d’API est automatiquement proposée.

Informations de référence sur les modèles ARM

Les informations de référence sur les modèles ARM sont une source d’informations sur la structure, les types de ressources, les versions d’API et les définitions de propriété des modèles ARM pour les ressources Azure. La documentation fournit des exemples à la fois au format Bicep et JSON.

Vous pouvez choisir des fournisseurs de ressources et des types de ressources spécifiques, comme Microsoft.Web/serverfarms et leurs versions d’API. Vous pouvez passer en revue les propriétés de ressource qui sont nécessaires et celles qui sont facultatives. Vous pouvez également voir des descriptions des propriétés, qui vous aident à comprendre ce que font ces propriétés.

Modèles de démarrage rapide Microsoft Azure

Le référentiel Modèles de démarrage rapide Azure est une collection de modèles fournis par la communauté. Ce référentiel de modèles où vous pouvez faire des recherches fournit des exemples pour de nombreuses ressources et solutions Azure. Dans certains modèles de démarrage rapide, vous pouvez voir à la fois un modèle ARM JSON et un modèle ARM Bicep. Vous pouvez utiliser ces modèles comme point de référence pour créer et vérifier vos modèles destinés au déploiement.

Supposons par exemple que vous voulez trouver un modèle qui crée un plan Azure App Service et une application. Chaque modèle de démarrage rapide vous donne la possibilité de déployer le modèle directement sur Azure ou de voir le modèle sur GitHub.

Gardez à l’esprit que les modèles de démarrage rapide Azure sont des contributions de la communauté. Certains des exemples peuvent être obsolètes, car des fonctionnalités sont régulièrement ajoutées aux services Azure. Les exemples peuvent également contenir des ressources et des propriétés dont vous n’avez pas besoin pour votre utilisation du modèle. Toutefois, le référentiel de modèles de démarrage rapide est une ressource utile pour vous aider à comprendre comment vous pouvez déployer vos ressources avec des modèles ARM.