Publier du code Bicep à partir d’un workflow de déploiement

• 5 minutes

Lorsque vous automatisez le processus de publication d’une spécification de modèle ou d’un module Bicep, vous devez vous assurer que tout ce que vous effectuez normalement vous-même peut être automatisé et exécuté dans le workflow. Dans cette unité, vous allez apprendre à appliquer certains des principes que vous avez précédemment appris lorsque vous publiez des spécifications de modèle et des modules Bicep à partir d’un workflow de déploiement.

Modules et spécifications de modèle

Bicep vous permet de réutiliser facilement votre code. Deux approches courantes pour réutiliser votre code Bicep entre les déploiements sont les suivantes :

• Spécifications de modèle, qui sont optimisées pour le déploiement de solutions complètes. Par exemple, supposons que vous avez défini un ensemble de ressources à la sécurité renforcée pour déployer une machine virtuelle complète en fonction des spécifications de votre entreprise. Vous pouvez publier ce code en tant que spécification de modèle. Vos collègues peuvent ensuite utiliser votre spécification de modèle pour déployer une machine virtuelle complète, même à partir du Portail Azure.
• Modules, conçus pour être des composants d’autres déploiements. Par exemple, supposons que vous avez créé un fichier Bicep qui crée un compte de stockage. Vous avez probablement besoin de comptes de stockage dans de nombreux autres déploiements. Vous pouvez donc publier le fichier Bicep dans un registre et l’utiliser comme module dans les différents déploiements de votre organisation.

Lorsque vous choisissez entre les specs de modèle et les modules Bicep, une bonne règle empirique est : si le modèle va être déployé tel quel dans votre organisation, les specs de modèle sont probablement mieux adaptés. Toutefois, si vous êtes susceptible de réutiliser ce modèle dans plusieurs modèles parents, les modules Bicep peuvent répondre à vos besoins.

Valider le code réutilisable dans un workflow

Contrairement aux déploiements Bicep classiques, lorsque vous créez une spécification de modèle ou un module, vous ne déployez pas les ressources directement sur Azure. Au lieu de cela, vous publiez le module ou la spécification de modèle. Vous pouvez ensuite utiliser le module ou la spécification de modèle dans un autre déploiement. Ce déploiement déploie les ressources que vous avez définies. En raison de cette différence, les façons dont vous validez et testez vos spécifications de modèle et modules Bicep peuvent être différentes du processus que vous utilisez pour les déploiements Bicep classiques.

Le linting de votre code Bicep est une bonne pratique. Le linter détecte les problèmes syntactiques et vous avertit si vous ne suivez pas les pratiques recommandées.

Au-delà du linting, vous pouvez envisager de tester vos modules et spécifications de modèle à l’aide de la validation préliminaire. Vous pouvez même envisager de déployer vos modules et spécifications de modèle sur Azure et de vérifier que les ressources qu’ils créent se comportent comme prévu. Toutefois, il peut être difficile d’exécuter ces types de tests à partir d’un workflow de déploiement pour deux raisons :

• Les déploiements et validations préliminaires nécessitent un environnement Azure sur lequel déployer les ressources. Vous devrez peut-être gérer un abonnement ou un groupe de ressources Azure dédié à utiliser pour déployer et tester vos modules.
• Un grand nombre de modules et de spécifications de modèle vous obligent à spécifier un ensemble de paramètres. Vous devrez peut-être créer un ensemble de paramètres pour vos modules ou spécifications de modèle à utiliser lors de leur déploiement.

Vous devez choisir d’inclure des étapes de workflow qui déploient et testent vos modules et spécifications de modèle. Dans ce module de formation Microsoft Learn, nous litons le code Bicep, mais n’incluons pas d’autres formes de test. Si vous souhaitez tester vos modules et spécifications de modèle, pensez à la façon dont vous allez les déployer sur Azure. Prenez également en compte si vous utiliserez des abonnements ou des groupes de ressources dédiés pour déployer les ressources.

Authentification et autorisation

Lorsque vous publiez des spécifications de modèle sur Azure vous-même, votre utilisateur Microsoft Entra doit être autorisé à accéder au groupe de ressources qui contient la ressource de spécification de modèle. De même, lorsque vous publiez un module Bicep dans un registre, votre utilisateur Microsoft Entra doit avoir l’autorisation d’écrire dans l’instance Azure Container Registry que votre organisation utilise pour ses modules Bicep.

Lorsque vous utilisez un workflow de déploiement automatisé, les mêmes principes s’appliquent. Toutefois, étant donné que vous n’êtes pas la personne qui exécute le déploiement, vous devez vous assurer que l’identité de votre workflow dispose de l’accès approprié au groupe de ressources pour la publication de la spec de modèle ou au registre de conteneurs pour la publication de modules.

Publier des modules et des spécifications de modèle à partir d’un workflow

Lorsque vous publiez une spécification de modèle à partir de votre propre ordinateur à l’aide d’Azure CLI, vous utilisez une commande comme celle-ci :

az ts create \
  --name StorageWithoutSAS \
  --location westus3 \
  --display-name "Storage account with SAS disabled" \
  --description "This template spec creates a storage account, which is preconfigured to disable SAS authentication." \
  --version 1 \
  --template-file main.bicep

Vous pouvez convertir cette commande Azure CLI en une étape GitHub Actions :

- name: Publish template spec
  uses: azure/cli@v1
  with:
    inlineScript: |
      az ts create \
        --name StorageWithoutSAS \
        --location westus3 \
        --display-name "Storage account with SAS disabled" \
        --description "This template spec creates a storage account, which is preconfigured to disable SAS authentication." \
        --version 1 \
        --template-file main.bicep

Le workflow utilise le même processus que vous pour publier la spécification de modèle.

De même, lorsque vous publiez un module Bicep à partir de votre propre ordinateur à l’aide d’Azure CLI, vous utilisez une commande comme celle-ci :

az bicep publish \
   --file module.bicep \
   --target 'br:toycompany.azurecr.io/mymodules/myqueue:2'

Vous pouvez également convertir cette commande Azure CLI en une étape GitHub Actions :

- name: Publish Bicep module
  uses: azure/cli@v1
  with:
    inlineScript: |
      az bicep publish \
        --file module.bicep \
        --target 'br:toycompany.azurecr.io/mymodules/myqueue:2'

Bientôt, vous verrez comment publier une spécification de modèle à partir d’un workflow à l’aide des étapes décrites dans cette unité.

Utiliser un module ou une spécification de modèle

Dans les modules de formation Microsoft Learn précédents, vous avez appris à déployer les ressources définies dans les spécifications de modèle et à utiliser des modules Bicep stockés dans des registres. Que vous publiiez vos modules et spécifications de modèle manuellement ou à partir d’un workflow de déploiement, vous les utilisez et les déployez de la même façon.

Par exemple, vous déployez une spécification de modèle ou un fichier Bicep sur un groupe de ressources à l’aide de la commande Azure CLI az deployment group create ou de l’applet de commande New-AzResourceGroupDeployment avec Azure PowerShell.