Tester et déployer votre modèle converti

Effectué

Après avoir amélioré votre fichier Bicep pendant la phase de refactorisation, vous devez tester votre fichier et le déployer sur votre environnement Azure. Les quatrième et cinquième phases du workflow recommandé sont la phase de test et la phase de déploiement :

Diagram that shows the test and deploy phases of the recommended workflow for migrating Azure resources to Bicep.

L’objectif principal de ces deux phases est de tester votre fichier Bicep en utilisant les outils disponibles, puis de le déployer sur votre environnement Azure.

Phase de test

Les objectifs de la phase de test de la migration de vos ressources vers Bicep sont 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 cet ordre :

  1. Exécuter l’opération de simulation de déploiement du modèle ARM.
  2. Effectuer un déploiement test.

Diagram that shows a Bicep file being tested and deployed to Azure.

L’opération de simulation donne un aperçu des modifications qui seront apportées lors du déploiement de votre fichier Bicep. Vous utilisez un déploiement de test pour comparer vos ressources d’origine aux ressources nouvellement déployées.

Qu’est-ce que l’opération de simulation de déploiement du modèle ARM ?

Quand vous déployez de nouvelles ressources ou que vous modifiez des ressources existantes, il est possible que des changements cassants soient introduits dans vos environnements. Votre déploiement risque de modifier ou supprimer des ressources existantes, créer des ressources incorrectement configurées ou affecter le fonctionnement global de votre application.

L’opération de simulation de déploiement de modèles ARM peut vous aider à vérifier vos modèles convertis avant de les déployer. Elle compare l’état actuel de votre environnement à l’état attendu qui est 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. Ce processus peut accroître votre niveau de confiance dans vos déploiements. 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. L’exécution de l’opération de simulation vous permet d’identifier les ressources que vous avez peut-être oubliées par inadvertance dans votre modèle.

Notes

L’opération de simulation risque de lister des propriétés de ressource comme étant supprimées, alors qu’en fait elles ne vont pas changer. Ces résultats sont considérés comme du bruit.

Tester le déploiement

Avant d’introduire votre modèle Bicep converti en production, pensez à exécuter plusieurs déploiements test. Si vous avez plusieurs environnements (production, développement, test), 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.

Conseil

Si vous n’avez pas accès à un environnement hors production pour tester votre déploiement, déployez votre modèle Bicep dans un nouvel environnement.

Phase de déploiement

L’objectif de la phase de déploiement de la migration de vos ressources vers Bicep est de déployer votre fichier Bicep final en production. Avant le déploiement en production, vous devez tenir compte de quelques aspects.

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

  1. Préparer un plan de restauration.
  2. Exécuter l’opération de simulation sur l’environnement de production.
  3. Déployez manuellement le fichier Bicep.
  4. Effectuer des tests de détection de fumée.

Ces étapes vous aident à vous préparer à d’éventuels problèmes rencontrés avec des déploiements en production.

Diagram that shows a Bicep file being deployed to Azure.

Préparer un plan de restauration

La possibilité de récupérer à partir d’un déploiement qui a échoué est cruciale. Consacrez du temps à développer un plan de restauration à utiliser si des changements cassants sont introduits dans vos environnements. Votre plan doit prendre en compte la stratégie de continuité d’activité et de reprise d’activité (BCDR) de votre organisation. Faites l’inventaire des types de ressources qui sont déployées, comme les machines virtuelles, les applications web et les bases de données. Vous devez également prendre en compte le plan de données de chaque ressource. 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 sa suppression ou de récupérer les données d’un compte de stockage ? 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.

Exécuter l’opération de simulation sur l’environnement de production

Vous avez déjà exécuté l’opération de simulation sur vos autres environnements pour vérifier que votre nouveau fichier Bicep n’entraîne pas de changements cassants. Avant de déployer votre fichier Bicep final en production, exécutez l’opération de simulation sur votre environnement de production. Veillez à utiliser des valeurs de paramètre de production et pensez à documenter les résultats.

Déployer manuellement

Si vous prévoyez d’utiliser le modèle converti dans un pipeline, comme dans Azure DevOps ou GitHub Actions, envisagez d’exécuter d’abord le déploiement depuis votre machine locale. Il est préférable de vérifier le fonctionnement du modèle avant de l’ajouter à votre pipeline de production. Une fois que vous avez vu comment le modèle fonctionne, vous pouvez réagir rapidement en cas de problème.

Effectuer des tests de détection de fumée

Une fois votre déploiement terminé, il est judicieux d’exécuter une série de tests de détection de fumée. Un test de détection de fumée est une vérification simple qui valide le bon fonctionnement de votre application ou de votre charge de travail. 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. Pour les machines virtuelles, connectez-vous à celles-ci et vérifiez que tous les services sont opérationnels.