ITSec France

Générer du Terraform depuis une évaluation Azure Migrate

Générer du Terraform depuis une évaluation Azure Migrate

Azure Migrate sait désormais produire du Terraform à partir d’une évaluation. Vous terminez une évaluation de charges de travail ou d’application, vous cliquez sur Generate IaC, et vous récupérez une archive contenant une zone d’atterrissage applicative prête à déployer, alimentée par les données de dimensionnement issues de l’évaluation.

L’idée est excellente. La mise en œuvre comporte deux contraintes qui déterminent si la fonctionnalité vous servira ou non. Autant les connaître avant d’y consacrer une journée.

La contrainte qui décide de tout

Le générateur ne propose qu’une seule architecture : un modèle trois tiers — frontal, applicatif, base de données — que Microsoft décrit explicitement comme optimisé pour des applications de développement non critiques. Si votre application ne rentre pas dans ce moule, le code généré est un point de départ à retravailler, pas un livrable.

Le flux complet, en six étapes

C’est le point le plus mal compris : la génération de code ne remplace pas la migration. Les deux se déroulent en parallèle, puis se rejoignent.

Étape Action Où
1 Générer le code applicatif depuis l’évaluation Portail Azure Migrate
2 Déployer la zone d’atterrissage applicative Terraform, chez vous
3 Migrer les serveurs Outil Server Migration
4 Détacher les disques de données et générer leur configuration Script PowerShell externe
5 Fusionner la configuration de disques avec le code applicatif Éditeur
6 Réappliquer le code applicatif Terraform, chez vous

Autrement dit : vous déployez une infrastructure vide, vous migrez les serveurs séparément, puis vous récupérez leurs disques pour les rattacher au code. Ce n’est pas un flux « générer et déployer », c’est un aller-retour.

Générer le code depuis l’évaluation

Le prérequis

Une évaluation de machines virtuelles Azure terminée, qu’elle porte sur des charges de travail ou sur une application. Sans elle, aucun bouton de génération n’apparaît — le générateur se nourrit exclusivement des données d’évaluation.

Le parcours

Depuis le rapport d’évaluation, Generate IaC ouvre un assistant. Trois points de vigilance à cet endroit :

  • Cibles IaaS uniquement. Aucune génération vers App Service, AKS ou les services managés. Ce sont des machines virtuelles et leur périphérie.
  • Sur une évaluation de charges de travail, vous choisissez les serveurs à inclure.
  • Sur une évaluation d’application, une seule application à la fois. Pour un portefeuille de quinze applications, c’est quinze passages dans l’assistant.

Ce que contient l’archive

Après génération, vous téléchargez une archive à ouvrir dans un éditeur. Les fichiers qui comptent :

vm_config.json      Configuration des machines, alimentée
                    automatiquement depuis l'évaluation

terraform.tfvars    Variables du déploiement, dont la ligne
                    de rattachement des disques, commentée
                    par défaut

readme.md           Procédure de déploiement et explication
                    du traitement des disques par Terraform

Le fichier vm_config.json est l’apport réel de la fonctionnalité : les tailles de machines proviennent du dimensionnement calculé par l’évaluation, pas d’un choix arbitraire. C’est ce qui évite le surdimensionnement systématique que l’on observe quand les équipes reprennent les caractéristiques des serveurs physiques d’origine.

L’architecture imposée

Le générateur ne connaît qu’un seul modèle : trois tiers, frontal, applicatif et base de données, avec des bonnes pratiques de sécurité alignées sur le Cloud Adoption Framework.

La mention à retenir figure dans la documentation Microsoft elle-même : cette architecture est optimisée pour des applications de développement non critiques. Ce n’est pas une précaution de langage, c’est une indication de périmètre.

Concrètement, ce que le modèle ne couvre pas :

  • Haute disponibilité multi-zones ou multi-régions
  • Architectures qui ne se découpent pas en trois tiers — cluster de calcul, serveur de fichiers, applicatif monolithique
  • Topologies réseau d’entreprise avec appairage, pare-feu centralisé, routage forcé
  • Toute cible qui ne soit pas de la machine virtuelle

Pour un environnement de développement ou de recette à reconstruire à l’identique plusieurs fois, c’est exactement ce qu’il faut. Pour de la production, considérez le code généré comme une base de départ documentée, à reprendre.

Le parcours des disques, qui surprend tout le monde

C’est la partie la moins intuitive, et celle qui explique pourquoi le flux compte six étapes plutôt que deux.

Le code généré crée des machines vierges. Vos données, elles, arrivent par la migration classique. Il faut donc récupérer les disques des machines migrées et les rattacher aux ressources décrites par le code :

  • Un script de migration de disques, hébergé dans le dépôt GitHub Azure/AzMigrate-Hydration, détache les disques de données de la machine migrée et produit un fichier disk-config.json
  • Ce fichier se copie dans le dossier du code applicatif
  • Dans terraform.tfvars, on décommente la ligne de rattachement :
# Dans terraform.tfvars, retirer le commentaire :
disk_config_file = "./disk-config.json"
  • Puis on réapplique le code, qui intègre cette fois les disques

À tester hors production, sans exception

Cette séquence détache des disques de données d’une machine virtuelle migrée, puis réapplique un plan Terraform par-dessus. Une erreur de correspondance entre le fichier de configuration et les ressources décrites peut détruire ou détacher les mauvais volumes. Déroulez le scénario complet sur une application de test avant d’y soumettre quoi que ce soit d’important, et vérifiez systématiquement le plan Terraform avant application.

Où c’est rentable, où ça ne l’est pas

Mon appréciation, à confronter à votre contexte.

Rentable

  • Migration par vagues. Dès la deuxième vague, le code se réutilise et le dimensionnement reste cohérent d’une vague à l’autre.
  • Environnements hors production à reconstruire souvent. Développement, recette, démonstration : c’est le cas d’usage pour lequel l’architecture a été pensée.
  • Reprise du dimensionnement. Même si vous jetez le reste du code, le vm_config.json issu de l’évaluation vaut le détour : il matérialise le travail d’analyse au lieu de le laisser dans un rapport.
  • Équipes sans pratique Terraform établie. Le code généré fournit une structure de départ conforme au Cloud Adoption Framework, ce qui vaut mieux que la première tentative maison.

Peu rentable

  • Vous avez déjà des modules Terraform maison. Les vôtres correspondent à vos conventions de nommage, votre topologie réseau et vos règles de marquage. Repartir du code généré vous ferait reculer.
  • Portefeuille applicatif hétérogène. Une application à la fois, une seule architecture : le compte n’y est pas.
  • Production critique. Le modèle ne couvre ni la haute disponibilité ni les topologies réseau d’entreprise.

Ce que je ferais

Générer le code sur une application représentative, même sans intention de le déployer tel quel. La lecture du résultat vous apprend deux choses : comment Microsoft traduit une évaluation en ressources concrètes, et si votre propre outillage produit mieux.

Ensuite, ne conservez que ce qui vous sert. Dans la plupart des parcs déjà outillés, ce sera le fichier de configuration des machines — le dimensionnement issu de l’évaluation, réinjecté dans vos modules à vous.

Cette fonctionnalité s’inscrit dans la même logique que l’agent Copilot de migration, que j’ai détaillé dans cet article sur la migration assistée par IA : Microsoft accélère l’analyse et la préparation, mais laisse intégralement la bascule et l’adaptation à votre contexte.

Sources