Gérer les différences entre les environnements à l’aide des paramètres Bicep

7 minutes

Vous avez déjà fait connaissance avec les paramètres Bicep. Ils vous permettent de spécifier des valeurs qui peuvent changer selon les déploiements de vos fichiers Bicep.

Souvent, vous utilisez des paramètres pour prendre en charge les différences entre vos environnements. Par exemple, dans vos environnements hors production, vous voulez souvent déployer des références SKU abordables de vos ressources Azure. En production, vous voulez déployer des références SKU qui offrent de meilleures performances. Vous voulez peut-être aussi utiliser des noms différents pour les ressources dans chaque environnement.

Lorsque vous déployez votre fichier Bicep, vous fournissez des valeurs pour chaque paramètre. Il existe plusieurs options pour spécifier les valeurs de chaque paramètre à partir de votre pipeline et pour spécifier des valeurs distinctes pour chaque environnement. Dans cette unité, vous allez découvrir les approches permettant de spécifier les valeurs des paramètres Bicep dans un pipeline de déploiement.

Fichiers de paramètres

Un fichier de paramètres est un fichier au format JSON qui liste les valeurs de paramètre à utiliser pour chaque environnement. Vous envoyez le fichier de paramètres à Azure Resource Manager quand vous envoyez le déploiement.

Voici un exemple de fichier de paramètres :

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "reviewApiUrl": {
      "value": "https://sandbox.contoso.com/reviews"
    }
  }
}

Les fichiers de paramètres peuvent être validés dans votre dépôt Git en même temps que votre fichier Bicep. Vous pouvez ensuite faire référence au fichier de paramètres dans votre modèle de pipeline dans lequel vous exécutez votre déploiement.

Il est judicieux d’établir une stratégie de nommage d’environnement cohérente pour les fichiers de paramètres. Par exemple, vous pouvez nommer vos fichiers de paramètres parameters.ENVIRONMENT_NAME.json, comme parameters.Production.json. Ensuite, vous pouvez utiliser un paramètre de modèle de pipeline pour sélectionner automatiquement le fichier de paramètres approprié.

parameters: 
- name: environmentType
  type: string
- name: serviceConnectionName
  type: string
- name: resourceGroupName
  type: string

- stage: Deploy
  jobs:
  - deployment: DeployWebsite
    displayName: Deploy Website
    environment: Website
    strategy:
      runOnce:
        deploy:
          steps:
            - checkout: self
            - task: AzureCLI@2
              name: DeployBicepFile
              displayName: Deploy Bicep file
              inputs:
                azureSubscription: ${{parameters.serviceConnectionName}}
                scriptType: 'bash'
                scriptLocation: 'inlineScript'
                inlineScript: |
                  az deployment group create \
                    --resource-group ${{parameters.resourceGroupName}} \
                    --template-file deploy/main.bicep \
                    --parameters deploy/azuredeploy.parameters.${{parameters.environmentType}}.json

Lorsque vous utilisez des fichiers de paramètres, vos fichiers YAML de pipeline n’ont pas besoin de contenir une liste de paramètres à transmettre individuellement à vos étapes de déploiement. Cela est particulièrement utile quand vous avez un grand nombre de paramètres.

Un fichier de paramètres réunit les valeurs de paramètre dans un seul fichier JSON. Les fichiers de paramètres font également partie de votre dépôt Git et peuvent donc être versionnés de la même façon que le reste de votre code.

Important

Les fichiers de paramètres ne doivent pas être utilisés pour les valeurs sécurisées. Il n’existe aucun moyen de protéger les valeurs des secrets dans les fichiers de paramètres et vous ne devez jamais valider de secrets dans votre dépôt Git.

Variables de pipeline

Azure Pipelines vous permet de stocker des variables de pipeline, qui sont utiles pour les valeurs qui peuvent différer d’un environnement à l’autre. Elles sont également utiles pour les valeurs que vous souhaitez définir une seule fois, puis réutiliser dans votre pipeline. Azure Pipelines prend en charge plusieurs façons de définir des variables.

Variables définies dans un fichier YAML

Vous pouvez définir des variables et leurs valeurs dans un fichier YAML. Cela est utile lorsque vous devez réutiliser la même valeur plusieurs fois. Toutefois, comme les fichiers de paramètres Bicep, les fichiers YAML ne conviennent pas pour des secrets.

Variables définies dans l’interface web

Vous pouvez définir des variables à l’aide de l’interface web Azure DevOps. Vous pouvez modifier les valeurs des variables à tout moment et le pipeline lira les valeurs mises à jour à sa prochaine exécution.

Les variables définies via l’interface web peuvent être marquées comme étant secrètes, ce qui indique à Azure Pipelines d’essayer de masquer les valeurs des variables dans les journaux de pipeline. Cela signifie que vous pouvez stocker des valeurs que votre fichier Bicep acceptera ensuite comme paramètres avec l’élément décoratif @secure().

Avertissement

Par défaut, Azure Pipelines obfusque les valeurs des variables secrètes dans les journaux de pipeline, mais vous devez également suivre les bonnes pratiques. Vos étapes de pipeline ont accès à toutes les valeurs de variables, y compris les secrets. Si votre pipeline inclut une étape qui ne gère pas une variable sécurisée en toute sécurité, il est possible que la variable secrète soit affichée dans les journaux de pipeline.

Groupes de variables

Vous pouvez également définir des groupes de variables, qui sont des ensembles de variables. À l’instar des variables, vous définissez ces groupes à l’aide de l’interface web Azure DevOps. Vous pouvez également utiliser des groupes de variables pour stocker en toute sécurité des secrets. Les groupes de variables peuvent même être réutilisés dans plusieurs pipelines dans le même projet Azure DevOps.

Contrairement aux autres variables, vous devez importer explicitement un groupe de variables dans un pipeline en utilisant le mot clé group dans une section variables, comme suit :

variables:
- group: MyVariableGroup

Lorsque vous utilisez des modèles de pipeline, vous pouvez nommer vos groupes de variables afin de pouvoir les charger facilement à l’aide d’un paramètre de modèle. Par exemple, supposons que votre pipeline se déploie dans deux environnements et que vous deviez définir un ensemble de variables pour chaque environnement. Vous pouvez nommer vos groupes de variables avec les noms d’environnement inclus, comme suit :

Nom de l’environnement	Nom du groupe de variables
Test	`ToyWebsiteTest`
Production	`ToyWebsiteProduction`

Dans chacun de ces groupes de variables, vous ajoutez des variables avec les mêmes noms, mais avec des valeurs différentes pour chaque environnement.

Votre fichier de modèle de pipeline utilise la macro {{ parameters.PARAMETER_NAME }} pour sélectionner le groupe de variables correct à importer :

parameters: 
- name: environmentType
  type: string
  default: 'Test'

variables: 
- group: ToyWebsite${{ parameters.environmentType }}

Groupes de variables Key Vault

Vous pouvez lier des groupes de variables à Azure Key Vault. Les secrets du coffre de clés sont rendus disponibles en tant que variables dans le groupe de variables. Les secrets peuvent ensuite être utilisés dans vos pipelines comme s’il s’agissait de variables normales.

Key Vault sécurise davantage la gestion de vos secrets. Cela permet également à votre équipe de sécurité de gérer ces valeurs et de séparer l’accès à vos pipelines des secrets qu’elle utilise.

Des étapes supplémentaires sont nécessaires pour lier un groupe de variables à un coffre de clés. Ces étapes incluent la création d’une connexion de service qui a l’autorisation de lire les secrets à partir du coffre de clés. Dans l’unité de résumé, nous proposons un lien vers plus de détails sur la configuration des groupes de variables Key Vault.

Utiliser des variables dans votre pipeline

Quelle que soit la façon dont vous définissez une variable, vous accédez à sa valeur dans votre pipeline en utilisant la syntaxe $(VariableName). Par exemple, lorsque vous exécutez un déploiement Bicep, vous pouvez utiliser une variable pour spécifier la valeur d’un paramètre :

- stage: Deploy
  jobs:
  - deployment: DeployWebsite
    displayName: Deploy Website
    environment: Website
    strategy:
      runOnce:
        deploy:
          steps:
            - checkout: self
            - task: AzureCLI@2
              name: DeployBicepFile
              displayName: Deploy Bicep file
              inputs:
                azureSubscription: MyServiceConnection
                scriptType: 'bash'
                scriptLocation: 'inlineScript'
                inlineScript: |
                  az deployment group create \
                    --resource-group $(ResourceGroupName) \
                    --template-file deploy/main.bicep \
                    --parameters environmentType=$(EnvironmentType)

Quelle est la meilleure approche ?

Vous avez vu plusieurs façons de gérer les paramètres dont votre fichier Bicep a besoin pour votre déploiement. Vous devez comprendre quand utiliser l’une ou l’autre de ces approches.

Éviter les paramètres inutiles

Les paramètres vous aident à rendre vos fichiers Bicep réutilisables, mais le risque est d’en définir un trop grand nombre. Quand vous déployez un fichier Bicep, vous devez fournir une valeur pour chaque paramètre. Dans les déploiements complexes sur plusieurs environnements, le nombre de valeurs de paramètre individuelles devient difficile à gérer.

Envisagez de rendre des paramètres facultatifs là où vous le pouvez et utilisez des valeurs par défaut qui s’appliquent à la plupart de vos environnements. Vous pouvez alors éviter à vos pipelines d’avoir à transmettre les valeurs des paramètres.

En outre, gardez à l’esprit que des paramètres sont souvent utilisés dans Bicep lorsque des ressources doivent se connecter à d’autres ressources. Par exemple, si vous avez un site web qui doit se connecter à un compte de stockage, vous devez fournir le nom et la clé d’accès du compte de stockage. Les clés sont des valeurs sécurisées. Toutefois, tenez compte de ces autres approches quand vous déployez cette combinaison de ressources :

Utilisez l’identité managée du site web pour accéder au compte de stockage. Quand vous créez une identité managée, Azure génère et gère automatiquement ses informations d’identification. Cette approche simplifie les paramètres de connexion. Cela signifie aussi que vous n’avez pas du tout besoin de gérer les secrets, c’est donc l’option la plus sécurisée.
Déployez le compte de stockage et le site web ensemble dans le même modèle Bicep. Utilisez des modules Bicep pour maintenir ensemble le site web et les ressources de stockage. Vous pouvez ensuite rechercher automatiquement les valeurs du nom et de la clé du compte de stockage dans le code Bicep au lieu de les passer dans des paramètres.
Ajoutez les détails du compte de stockage à un coffre de clés sous forme de secret. Le code du site web charge alors la clé d’accès directement à partir du coffre. Cette approche évite d’avoir à gérer la clé dans le pipeline.

Utiliser des groupes de variables pour de petits ensembles de paramètres

Si vous n’avez qu’un petit nombre de paramètres pour vos fichiers Bicep, envisagez d’utiliser un groupe de variables. Vous pouvez stocker des valeurs secrètes et non secrètes dans des groupes de variables.

Utiliser des fichiers de paramètres pour les grands ensembles de paramètres

Si vous avez un grand ensemble de paramètres pour vos fichiers Bicep, utilisez des fichiers de paramètres pour regrouper les valeurs non sécurisées pour chaque environnement. Ensuite, chaque fois que vous devez modifier les valeurs, vous pouvez mettre à jour un fichier de paramètres et valider vos modifications.

Cette approche permet de simplifier vos étapes de pipeline, car vous n’avez pas besoin de définir explicitement la valeur pour chaque paramètre.

Stocker les secrets en toute sécurité

Utilisez un processus approprié pour stocker et gérer les secrets. Si vous n’avez qu’un petit nombre de secrets à gérer, les variables et les groupes de variables Azure Pipelines fonctionnent souvent bien. Toutefois, vous pouvez avoir des exigences plus complexes, comme un grand nombre de secrets, de nombreux environnements différents ou des restrictions de contrôle d’accès. Pour de telles situations, envisagez de stocker les secrets pour chaque environnement dans des coffres de clés distincts. Utilisez des groupes de variables pour lier les coffres à votre pipeline.

Pour les paramètres sécurisés, n’oubliez pas de transmettre explicitement chaque paramètre dans vos étapes de déploiement.

Combiner les approches

Il est courant de combiner plusieurs approches pour gérer les paramètres. Par exemple, vous pouvez stocker la plupart de vos valeurs de paramètre dans des fichiers de paramètres, puis définir les valeurs sécurisées à l’aide d’un groupe de variables. L’exemple suivant illustre la combinaison :

variables:
- group: MyVariableGroup # This group imports a parameter named MySecureParameter.

stages:

- stage: Deploy
  jobs:
  - deployment: DeployWebsite
    displayName: Deploy Website
    environment: Website
    strategy:
      runOnce:
        deploy:
          steps:
            - checkout: self
            - task: AzureCLI@2
              name: DeployBicepFile
              displayName: Deploy Bicep file
              inputs:
                azureSubscription: MyServiceConnection
                scriptType: 'bash'
                scriptLocation: 'inlineScript'
                inlineScript: |
                  az deployment group create \
                    --resource-group ${{parameters.resourceGroupName}} \
                    --template-file deploy/main.bicep \
                    --parameters deploy/azuredeploy.parameters.${{parameters.environmentName}}.json \
                                 mySecureParameter=$(MySecureParameter)

Il existe des règles spéciales concernant la spécification des noms des connexions de service. Ces règles peuvent affecter la façon dont vous utilisez les noms dans les pipelines déployés dans plusieurs environnements. Par exemple, vous ne pouvez pas utiliser une variable définie dans un groupe de variables pour spécifier un nom de connexion de service. Vous pouvez utiliser des paramètres de modèle de pipeline pour spécifier le nom de la connexion de service à utiliser.

Continuer