Migrer des ressources Azure et des modèles ARM JSON pour utiliser Bicep

La définition de vos ressources Azure dans Bicep présente de nombreux avantages, notamment une syntaxe plus simple, la modularisation, la gestion automatique des dépendances, la validation de type IntelliSense et une expérience de création améliorée.

Quand vous migrez des modèles Azure Resource Manager (modèles ARM) JSON existants vers Bicep, nous vous recommandons de suivre le workflow en cinq phases :

La première étape du processus consiste à capturer une représentation initiale de vos ressources Azure. Si nécessaire, vous pouvez ensuite décompiler le fichier JSON en fichier Bicep initial, que vous améliorez avec la refactorisation. Si vous disposez d’un fichier de travail, vous le testez et le déployez à l’aide d’un processus qui réduit le risque de changement cassant à votre environnement Azure.

Dans cet article, nous récapitulons le workflow recommandé. Pour plus d’informations, consultez le module Learn Migrer des ressources Azure et des modèles ARM JSON pour utiliser Bicep.

Phase 1 : Conversion

Dans la phase de conversion de la migration de vos ressources vers Bicep, l’objectif 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, que vous effectuez dans l’ordre :

1. Capturez une représentation de vos ressources Azure. Si vous avez un modèle JSON existant que vous convertissez en Bicep, la première étape est simple, car vous disposez déjà de votre modèle source. Si vous convertissez des ressources Azure qui ont été déployées en utilisant le portail ou un autre outil, vous devez capturer les définitions de ressource. Vous pouvez capturer une représentation JSON de vos ressources à l’aide du portail Azure, d’Azure CLI ou des cmdlets Azure PowerShell pour exporter des ressources uniques, plusieurs ressources et des groupes de ressources complets. Pour importer une représentation Bicep de votre ressource Azure, vous pouvez utiliser la commande Insert Resource dans Visual Studio Code.

2. Si nécessaire, convertir la représentation JSON en Bicep en utilisant la commande décompiler.Les outils Bicep incluent la commande decompile pour convertir des modèles. Vous pouvez appeler la commande decompile à partir de Visual Studio Code avec l’extension Bicep, Azure CLI ou à partir de l’interface CLI Bicep. Le processus de décompilation est un processus qui ne produit pas un résultat parfait et ne garantit pas un mappage complet de JSON à Bicep. Il peut être nécessaire de réviser le fichier Bicep généré pour répondre aux bonnes pratiques dans votre modèle avant d’utiliser le fichier pour déployer des ressources.

Notes

Vous pouvez importer une ressource en ouvrant la palette de commandes Visual Studio Code. Sous Windows et Linux, appuyez sur Ctrl+Maj+P et sous macOS, sur ⌘+Maj+P.

Visual Studio Code vous permet de coller du code JSON en tant que Bicep. Pour plus d’informations, consultez Coller du code JSON en tant que commande Bicep.

Phase 2 : Migrer

Dans la phase de migration consistant à migrer vos ressources vers Bicep, l’objectif est de créer le premier brouillon 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. C’est une bonne pratique que de créer un fichier Bicep entièrement nouveau. 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.

2. Copier chaque ressource depuis votre modèle décompilé. Copiez chaque ressource individuellement depuis le fichier Bicep converti vers le nouveau fichier Bicep. Ce processus vous aide à résoudre les éventuels problèmes pour chaque ressource et à éviter toute confusion quand la taille de votre modèle s’accroît.

3. Identifier et recréer les ressources manquantes. Tous les types de ressources Azure ne peuvent pas être exportés via le portail Azure, Azure CLI ou Azure PowerShell. Par exemple, les extensions de machine virtuelle, comme DependencyAgentWindows et MMAExtension (Microsoft Monitoring Agent), ne sont pas des types de ressources pris en charge pour l’exportation. Pour les ressources qui n’ont pas été exportées, telles que les extensions de machine virtuelle, vous devez recréer ces ressources dans votre nouveau fichier Bicep. Vous pouvez recréer des ressources en utilisant divers outils et approches, notamment Azure Resource Explorer, la documentation de référence des modèles Bicep et ARM et le site Modèles de démarrage rapide Azure.

Phase 3 : Refactorisation

Dans la phase de refactorisation de la migration de vos ressources vers Bicep, l’objectif est d’améliorer la qualité de votre code Bicep. Ces améliorations peuvent comprendre des changements, comme l’ajout de commentaires de code qui alignent le modèle sur les standards de vos modèles.

La phase de déploiement comprend huit étapes, que vous effectuez dans n’importe quel ordre :

1. Passer en revue les versions d’API des ressources. Quand vous exportez des ressources Azure, le modèle exporté risque de ne pas contenir la dernière version de l’API pour un type de ressource. Si vous avez besoin de propriétés spécifiques pour des déploiements futurs, mettez à jour l’API vers la version appropriée. C’est une bonne pratique que de passer en revue les versions d’API pour chaque ressource exportée.

2. Passer en revue les suggestions du linter dans votre nouveau fichier Bicep. Quand vous utilisez l’extension Bicep pour Visual Studio Code pour créer des fichiers Bicep, le linter Bicep s’exécute automatiquement, et met en surbrillance les suggestions et les erreurs dans votre code. La plupart des suggestions et des erreurs incluent une option permettant d’appliquer un correctif rapide au problème. Passez en revue ces recommandations et modifiez votre fichier Bicep.

3. Réviser les paramètres, les variables et les noms symboliques. Il est possible que les noms des paramètres, variables et noms symboliques générés par le décompileur ne correspondent pas à votre convention d’affectation de noms standard. Examinez les noms générés et apportez les modifications nécessaires.

4. Simplifier les expressions. Le processus de décompilation peut ne pas toujours tirer parti de certaines fonctionnalités de Bicep. Passez en revue les expressions générées dans la conversion et simplifiez-les. Par exemple, le modèle décompilé peut inclure une fonction concat() ou format() qui peut être simplifiée en utilisant une interpolation de chaîne. Passez en revue les suggestions du linter et apportez les modifications nécessaires.

5. Passer en revue les ressources enfants et d’extension. Il y a plusieurs façons de déclarer des ressources enfants et des ressources d’extension dans Bicep, notamment la concaténation des noms de vos ressources, l’utilisation du mot clé parent et l’utilisation des ressources imbriquées. Envisagez de passer en revue ces ressources après la décompilation et vérifiez que la structure correspond à vos standards. Par exemple, veillez à ne pas utiliser la concaténation de chaînes pour créer des noms de ressources enfants : vous devez utiliser la propriété parent ou une ressource imbriquée. De même, les sous-réseaux peuvent être référencés en tant que propriétés d’un réseau virtuel ou en tant que ressource distincte.

6. Modulariser. Si vous convertissez un modèle qui contient un grand nombre de ressources, pour des raisons de simplicité, envisagez de diviser les différents types de ressources en modules. Les modules Bicep permettent de réduire la complexité de vos déploiements et d’augmenter la réutilisation de votre code Bicep.

   Notes

   Il est possible d’utiliser vos modèles JSON comme modules dans un déploiement Bicep. Bicep a la capacité de reconnaître les modules JSON et de les référencer de la même façon que vous utilisez les modules Bicep.

7. Ajouter des commentaires et des descriptions. Tout bon code Bicep est auto-documenté. Bicep vous permet d’ajouter des commentaires et des attributs @description() à votre code pour vous aider à documenter votre infrastructure. Bicep prend en charge les commentaires sur une seule ligne avec une séquence de caractères //, et les commentaires multilignes qui commencent par /* et se terminent par */. Vous pouvez ajouter des commentaires à des lignes spécifiques de votre code et à des sections du code.

8. Suivre les bonnes pratiques de Bicep. Vérifiez que votre fichier Bicep suit les recommandations standard. Consultez le document de référence Bonnes pratiques de Bicep pour voir ce que vous auriez pu oublier.

Phase 4 : Test

Dans la phase de test de la migration de vos ressources vers Bicep, l’objectif est de vérifier l’intégrité de vos modèles migrés et d’effectuer un déploiement de test.

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

1. Exécuter l’opération de simulation de déploiement du modèle ARM. Pour vous aider à vérifier vos modèles convertis avant un déploiement, vous pouvez utiliser l’opération de simulation de déploiement de modèle Azure Resource Manager. Elle compare l’état actuel de votre environnement à l’état souhaité défini dans le modèle. L’outil génère la liste des modifications qui vont se produire sans appliquer les modifications à votre environnement. Vous pouvez utiliser la simulation avec des déploiements en mode incrémentiel et complet. Même si vous prévoyez de déployer votre modèle en utilisant le mode incrémentiel, il est judicieux d’exécuter votre opération de simulation en mode complet.

2. Effectuer un déploiement de test. Avant d’introduire votre modèle Bicep converti en production, pensez à exécuter plusieurs déploiements de test. Si vous avez plusieurs environnements (par exemple développement, test et production), vous pouvez d’abord essayer de déployer votre modèle sur l’un de vos environnements hors production. Après le déploiement, comparez les ressources d’origine avec les nouveaux déploiements de ressources pour en vérifier la cohérence.

Phase 5 : Déploiement

Dans la phase de déploiement de la migration de vos ressources vers Bicep, l’objectif est de déployer votre fichier Bicep final en production.

La phase de déploiement se compose de quatre étapes, que vous effectuez dans l’ordre :

1. Préparer un plan de restauration. La possibilité de récupérer à partir d’un déploiement qui a échoué est cruciale. Créez une stratégie de restauration si des changements cassants sont introduits dans vos environnements. Effectuez l’inventaire des types de ressources qui sont déployées, comme les machines virtuelles, les applications web et les bases de données. Le plan de données de chaque ressource doit également être pris en compte. Avez-vous un moyen de récupérer une machine virtuelle et ses données ? Avez-vous un moyen de récupérer une base de données après suppression ? Un plan de restauration correctement développé permet de réduire au minimum votre temps d’arrêt en cas de problème lors d’un déploiement.

2. Exécuter l’opération de simulation sur l’environnement de production. Avant de déployer votre fichier Bicep final en production, exécutez l’opération de simulation sur votre environnement de production, en veillant à utiliser les valeurs des paramètres de production et à documenter les résultats.

3. Déployer manuellement. Si vous prévoyez d’utiliser le modèle converti dans un pipeline, comme Azure DevOps ou GitHub Actions, exécutez d’abord le déploiement à partir de votre machine locale. Il vaut mieux tester les fonctionnalités du modèle avant de l’incorporer dans votre pipeline de production. De cette façon, vous pouvez répondre rapidement en cas de problème.

4. Effectuer des tests de détection de fumée. Une fois votre déploiement terminé, vous devez exécuter une série de tests de détection de fumée pour vérifier que votre application ou votre charge de travail fonctionne correctement. Par exemple, testez pour voir si votre application web est accessible via des canaux d’accès normaux, comme l’Internet public ou sur un VPN d’entreprise. Pour les bases de données, essayez d’établir une connexion de base de données et d’exécuter une série de requêtes. Avec les machines virtuelles, connectez-vous à la machine virtuelle et assurez-vous que tous les services sont opérationnels.

Étapes suivantes

Pour en savoir plus sur le décompileur Bicep, consultez Décompiler le modèle ARM JSON vers Bicep.