Publier du code Bicep à partir d’un pipeline 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 manuellement peut être automatisé et exécuté dans le pipeline. Dans cette unité, vous appliquez des principes que vous avez appris précédemment à publier des spécifications de modèle et des modules Bicep à partir d’un pipeline 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 pipeline

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 ensuite les ressources que vous avez définies. Par conséquent, les méthodes que vous validez et testez vos specs de modèle et les modules Bicep peuvent différer du processus que vous utilisez pour les déploiements Bicep standard.

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 pipeline 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 décider s’il faut inclure des étapes de pipeline qui déploient et testent vos spécifications et modules de modèle. Dans ce module Microsoft Learn, nous litons le code Bicep, mais n’incluons pas d’autres formes de test. Si vous souhaitez tester vos specs et modules de modèle, réfléchissez à la façon dont vous les déployez sur Azure. Déterminez également s’il faut utiliser des abonnements dédiés ou des groupes de ressources pour déployer les ressources.

Conseil

Nous vous recommandons de consulter la page Tester votre code Bicep à l’aide d’Azure Pipelines pour plus d’informations sur la façon de tester vos fichiers Bicep dans un pipeline automatisé.

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 pipeline 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 le principal de service de votre pipeline dispose de l’accès approprié au groupe de ressources pour la publication de la spécification de modèle ou au registre de conteneurs pour la publication de modules.

Conseil

Lorsque vous publiez un module dans un registre, le principal de service exécutant le déploiement n’a probablement pas besoin d’un grand nombre d’autorisations. Lorsque votre registre utilise l’autorisation Microsoft Entra, le principal de service n’a besoin que de l’autorisation AcrPush sur le registre.

Envisagez d’utiliser le principe de sécurité du privilège minimum. Fournissez au principal de service du pipeline un accès uniquement au registre de conteneurs et non à un groupe de ressources ou à un abonnement.

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

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 \
  --resource-group MyResourceGroup \
  --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 de pipeline :

- task: AzureCLI@2
  name: Publish
  displayName: Publish template spec
  inputs:
    azureSubscription: $(ServiceConnectionName)
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az ts create \
        --name StorageWithoutSAS \
        --resource-group MyResourceGroup \
        --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 pipeline 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 de pipeline :

- task: AzureCLI@2
  name: Publish
  displayName: Publish Bicep module
  inputs:
    azureSubscription: $(ServiceConnectionName)
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az bicep publish \
        --file module.bicep \
        --target 'br:toycompany.azurecr.io/mymodules/myqueue:2'

Conseil

Dans cet exemple, le nom d’hôte du registre Bicep (toycompany.azurecr.io) est incorporé dans la définition de l’étape de pipeline. Ce n’est pas une bonne pratique. Vous pouvez utiliser des variables d’environnement pour définir des paramètres de configuration comme ceci. Vous verrez comment cela fonctionne plus tard dans ce module Microsoft Learn.

La procédure de publication d’une spécification de modèle à partir d’un pipeline est décrite 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 pipeline 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.