Utiliser des secrets et des variables d’environnement dans azure Load Testing

Dans cet article, vous allez apprendre à passer des secrets et des environnements en tant que paramètres à un test de charge dans Azure Load Testing. Vous pouvez utiliser des paramètres pour modifier le comportement d’un test de charge sans avoir à modifier le script Apache JMeter. Par exemple, pour tester une application web, spécifiez l’URL du point de terminaison en tant que paramètre pour réutiliser votre script de test dans plusieurs environnements. Vous pouvez également utiliser des paramètres pour éviter que vous deviez coder en dur des informations sensibles dans le script de test JMeter.

Le service Test de charge Azure prend en charge deux types de paramètres :

  • Les secrets : contiennent des informations sensibles et sont transmis en toute sécurité au moteur de test de charge. Les secrets fournissent notamment des informations d’identification de service web au lieu d’effectuer un codage irréversible dans le script de test. Pour plus d’informations, consultez Configurer des tests de charge avec des secrets.

  • Les variables d’environnement : contiennent des informations non sensibles et sont disponibles en tant que variables d’environnement dans le moteur de test de charge. Par exemple, les variables d’environnement rendent l’URL du point de terminaison d’application configurable. Pour plus d’informations, consultez Configurer des tests de charge avec des variables d’environnement.

Vous pouvez spécifier des paramètres dans la configuration de test de charge lorsque vous créez un test ou mettez à jour un test existant. Si vous exécutez un test de charge dans votre flux de travail CI/CD, vous définissez des paramètres dans le fichier de configuration de test de charge ou dans la définition de flux de travail CI/CD.

Prérequis

  • Compte Azure avec un abonnement actif. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.

  • Une ressource de test de charge Azure. Si vous avez besoin de créer une ressource de test de charge Azure, consultez le guide de démarrage rapide Créer et exécuter un test de charge.

Configurer des tests de charge avec des secrets

Dans cette section, vous allez apprendre à passer des secrets à votre script de test de charge dans Test de charge Azure. Par exemple, vous pouvez utiliser un secret pour passer la clé API à un point de terminaison de service web sur lequel vous exécutez un test de charge. Au lieu de stocker la clé API dans la configuration ou de la coder de manière irréversible dans le script, vous pouvez l’enregistrer dans un magasin des secrets pour contrôler étroitement l’accès au secret.

Test de charge Azure vous permet de stocker des secrets dans Azure Key Vault. Par ailleurs, quand vous exécutez votre test de charge dans un pipeline CI/CD, vous pouvez également utiliser le magasin des secrets associé à votre technologie CI/CD, par exemple Azure Pipelines ou GitHub Actions.

Pour utiliser des secrets avec Test de charge Azure, effectuez les étapes suivantes :

  1. Stockez la valeur secrète dans le magasin des secrets (Azure Key Vault ou magasin des secrets CI/CD).
  2. Passez une référence au secret dans le script de test Apache JMeter.
  3. Utilisez la valeur du secret dans le script de test Apache JMeter à l’aide de la fonction personnalisée GetSecret.

Important

Vous ne pouvez utiliser la GetSecret fonction personnalisée que lorsque vous exécutez votre script de test JMeter avec Azure Load Testing. Si vous exécutez votre script de test localement, vous devez mettre à jour votre script de test et lire des valeurs secrètes de manière différente.

Utiliser Azure Key Vault pour stocker des secrets de test de charge

Vous pouvez utiliser Azure Key Vault pour passer des valeurs de secret à votre script de test dans Test de charge Azure. Vous ajoutez une référence au secret dans la configuration du test de charge Azure. Test de charge Azure utilise alors cette référence pour récupérer la valeur du secret dans le script Apache JMeter.

Vous devez également accorder à Azure Load Testing l’accès à votre coffre de clés Azure pour récupérer la valeur secrète.

Remarque

Si vous exécutez un test de charge dans le cadre de votre processus CI/CD, vous pouvez également utiliser le magasin de secrets associé. Passez à Utiliser le magasin de secrets CI/CD.

Créer un secret dans Azure Key Vault

  1. Ajoutez la valeur du secret à votre coffre de clés, si vous ne l’avez pas déjà fait.

    Important

    Si vous avez restreint l’accès à votre coffre de clés Azure par un pare-feu ou une mise en réseau virtuelle, procédez comme suit pour accorder l’accès aux services Azure approuvés.

  2. Récupérez l’identificateur de votre secret dans le coffre de clés. Vous utilisez cet identificateur secret pour configurer votre test de charge.

    Screenshot that shows the details of a secret in an Azure key vault.

    L’identificateur du secret correspond à son URI complet dans le coffre de clés Azure. Si vous le souhaitez, vous pouvez également inclure un numéro de version. Par exemple, https://myvault.vault.azure.net/secrets/mysecret/ ou https://myvault.vault.azure.net/secrets/mysecret/abcdef01-2345-6789-0abc-def012345678.

Ajouter le secret à votre test de charge

  1. Référencez le secret dans la configuration du test de charge.

    Définissez un paramètre de secret de test de charge pour chaque secret que vous référencez dans le script Apache JMeter. Le nom du paramètre doit correspondre au nom du secret utilisé dans le script de test Apache JMeter. La valeur du paramètre correspond à l’identificateur de sécurité du coffre de clés.

    Vous pouvez spécifier des paramètres secrets en procédant de l’une des façons suivantes :

    • Dans le portail Azure, sélectionnez votre test de charge, puisConfigurer. Choisissez l’onglet Paramètres et entrez les détails du paramètre.

      Screenshot that shows where to add secret details to a load test in the Azure portal.

    • Si vous configurez un workflow CI/CD et utilisez Azure Key Vault, vous pouvez spécifier un secret dans le fichier de configuration YAML à l’aide de la propriété secrets. Pour plus d’informations sur la syntaxe, consultez la page de référence sur le test de configuration YAML.

  2. Spécifiez l’identité que Test de charge Azure utilise pour accéder à vos secrets dans Azure Key Vault.

    Cette identité peut correspondre l’identité affectée par le système de la ressource de test de charge ou à l’une des identités affectées par l’utilisateur. Veillez à utiliser la même identité que celle à laquelle vous avez accordée l’accès précédemment.

    Vous pouvez spécifier l’identité de référence du coffre de clés en procédant de l’une des façons suivantes :

    • Dans le portail Azure, sélectionnez votre test de charge, sélectionnez Configurer, sélectionnez l’onglet Paramètres, puis configurez l’identité de référence du coffre de clés.

      Screenshot that shows how to select key vault reference identity.

    • Si vous configurez un workflow CI/CD et utilisez Azure Key Vault, vous pouvez spécifier l’identité de référence dans le fichier de configuration YAML à l’aide de la propriété keyVaultReferenceIdentity. Pour plus d’informations sur la syntaxe, consultez la page de référence sur le test de configuration YAML.

Accorder l’accès à votre coffre de clés Azure

Lorsque vous stockez des secrets de test de charge ou des certificats dans Azure Key Vault, votre ressource de test de charge utilise une identité managée pour accéder au coffre de clés. Après avoir configuré l’identité de gestion, vous devez accorder l’identité managée de vos autorisations de ressource de test de charge pour lire ces valeurs à partir du coffre de clés.

Pour accorder à votre ressource de test de charge Azure des autorisations pour lire des secrets ou des certificats à partir de votre coffre de clés Azure :

  1. Dans le portail Azure, accédez à votre ressource Azure Key Vault.

    Si vous n’avez pas encore de coffre de clés, suivez les instructions du démarrage rapide Azure Key Vault pour en créer un.

  2. Dans le volet gauche, sélectionnez Stratégies d’accès, puis sélectionnez + Créer.

  3. Sous l’onglet Autorisations, sous Autorisations secrètes, sélectionnez Obtenir, puis Sélectionnez Suivant.

    Remarque

    Azure Load Testing récupère les certificats en tant que secret pour s’assurer que la clé privée du certificat est disponible.

  4. Sous l’onglet Principal , recherchez et sélectionnez l’identité managée pour la ressource de test de charge, puis sélectionnez Suivant.

    Si vous utilisez une identité managée affectée par le système, le nom de l’identité managée correspond à celui de votre ressource de test de charge Azure.

  5. Cliquez à nouveau sur Suivant.

    Lorsque votre test s’exécute, l’identité managée associée à votre ressource de test de charge peut désormais lire les secrets ou certificats de votre test de charge à partir de votre coffre de clés.

Maintenant que vous avez ajouté un secret dans Azure Key Vault, configuré un secret pour votre test de charge, vous pouvez maintenant passer à Utiliser des secrets dans Apache JMeter.

Utiliser le magasin des secrets CI/CD pour enregistrer des secrets de test de charge

Si vous utilisez le test de charge Azure dans votre workflow CI/CD, vous pouvez également utiliser le magasin de secrets associé. Vous pouvez, par exemple, utiliser des secrets de référentiel GitHub ou des variables de secrets dans Azure Pipelines.

Remarque

Si vous utilisez déjà un coffre de clés, vous pouvez également l’utiliser pour stocker les secrets du test de charge. Passez à Utiliser Azure Key Vault.

Pour utiliser des secrets dans le magasin de secrets CI/CD et les transmettre à votre test de charge dans CI/CD :

  1. Ajoutez la valeur du secret au magasin de secrets CI/CD, s’il n’y existe pas encore.

    Dans Azure Pipelines, vous pouvez modifier le pipeline et ajouter une variable.

    Screenshot that shows how to add a variable to Azure Pipelines.

    Dans GitHub, vous pouvez utiliser des secrets de référentiel GitHub.

    Screenshot that shows how to add a GitHub repository secret.

    Remarque

    Veillez à utiliser la valeur de secret réelle et non l’identificateur de secret du coffre de clés comme valeur.

  2. Passez le secret en tant que paramètre d’entrée à la tâche/action Test de charge dans le workflow CI/CD.

    L’extrait de code YAML suivant montre comment passer le secret à l’action GitHub Test de charge :

    - name: 'Azure Load Testing'
      uses: azure/load-testing@v1
      with:
        loadtestConfigFile: 'SampleApp.yaml'
        loadtestResource: 'MyTest'
        resourceGroup: 'loadtests-rg'
        secrets: |
        [
            {
            "name": "appToken",
            "value": "${{ secrets.MY_SECRET }}"
            }
        ]
    

    L’extrait de code YAML suivant montre comment passer le secret à la tâche Azure Pipelines :

    - task: AzureLoadTest@1
      inputs:
        azureSubscription: 'MyAzureLoadTestingRG'
        loadTestConfigFile: 'SampleApp.yaml'
        loadTestResource: 'MyTest'
        resourceGroup: 'loadtests-rg'
        secrets: |
          [
              {
              "name": "appToken",
              "value": "$(mySecret)"
              }
          ]
    

    Important

    Le nom du paramètre d’entrée du secret doit correspondre au nom utilisé dans le script Apache JMeter.

Vous avez maintenant spécifié un secret dans le magasin des secrets CI/CD et passé une référence à Test de charge Azure. Vous pouvez maintenant utiliser le secret dans le script Apache JMeter.

Utiliser des secrets dans Apache JMeter

Ensuite, vous mettez à jour le script Apache JMeter pour utiliser le secret que vous avez spécifié précédemment.

Vous commencez par créer une variable définie par l’utilisateur qui récupère la valeur du secret. Ensuite, vous pouvez utiliser cette variable dans votre test (par exemple, pour passer un jeton d’API dans un en-tête de requête HTTP).

  1. Créez une variable définie par l’utilisateur dans votre fichier JMX et affectez-lui la valeur du secret à l’aide de la fonction personnalisée GetSecret.

    La fonction GetSecret(<my-secret-name>) prend le nom de secret comme argument. Le même nom sera utilisé lorsque vous configurerez le test de charge dans une étape ultérieure.

    Vous pouvez créer la variable définie par l’utilisateur à l’aide de l’IDE Apache JMeter, comme illustré dans l’image suivante :

    Screenshot that shows how to add user-defined variables to your Apache JMeter script.

    Vous pouvez également modifier directement le fichier JMX, comme illustré dans cet exemple d’extrait de code :

    <Arguments guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
      <collectionProp name="Arguments.arguments">
        <elementProp name="appToken" elementType="Argument">
          <stringProp name="Argument.name">udv_appToken</stringProp>
          <stringProp name="Argument.value">${__GetSecret(appToken)}</stringProp>
          <stringProp name="Argument.desc">Value for x-secret header </stringProp>
          <stringProp name="Argument.metadata">=</stringProp>
        </elementProp>
      </collectionProp>
    </Arguments>
    
  2. Référencez la variable définie par l’utilisateur dans le script de test.

    Vous pouvez utiliser la syntaxe ${} pour faire référence à la variable dans le script. Dans l’exemple suivant, vous utilisez la variable udv_appToken pour définir un en-tête HTTP.

      <HeaderManager guiclass="HeaderPanel" testclass="HeaderManager" testname="HTTP Header Manager" enabled="true">
        <collectionProp name="HeaderManager.headers">
          <elementProp name="" elementType="Header">
            <stringProp name="Header.name">api-key</stringProp>
            <stringProp name="Header.value">${udv_appToken}</stringProp>
          </elementProp>
        </collectionProp>
      </HeaderManager>
    

Configurer des tests de charge avec des variables d’environnement

Dans cette section, vous utilisez des variables d’environnement pour transmettre des paramètres à votre test de charge.

  1. Mettez à jour le script Apache JMeter pour utiliser la variable d’environnement (par exemple, pour configurer le nom d’hôte du point de terminaison d’application).

  2. Configurez le test de charge et transmettez la variable d’environnement au script de test.

Utiliser les variables d’environnement dans Apache JMeter

Dans cette section, vous allez mettre à jour le script Apache JMeter pour utiliser les variables d’environnement afin de contrôler le comportement du script.

Commencez par définir une variable définie par l’utilisateur qui lit la variable d’environnement, puis vous utilisez cette variable lors de l’exécution du test (par exemple, pour mettre à jour le domaine HTTP).

  1. Créez une variable définie par l’utilisateur dans votre fichier JMX et affectez-lui la valeur de la variable d’environnement à l’aide de la fonction System.getenv.

    La fonction System.getenv("<my-variable-name>") prend le nom de la variable d’environnement comme argument. Vous utilisez ce même nom lorsque vous configurez le test de charge.

    Vous pouvez créer une variable définie par l’utilisateur à l’aide de l’IDE Apache JMeter, comme illustré dans l’image suivante :

    Screenshot that shows how to add user-defined variables for environment variables to your JMeter script.

    Vous pouvez également modifier directement le fichier JMX, comme illustré dans cet exemple d’extrait de code :

    <Arguments guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
      <collectionProp name="Arguments.arguments">
        <elementProp name="appToken" elementType="Argument">
          <stringProp name="Argument.name">udv_webapp</stringProp>
          <stringProp name="Argument.value">${__BeanShell( System.getenv("webapp") )}</stringProp>
          <stringProp name="Argument.desc">Web app URL</stringProp>
          <stringProp name="Argument.metadata">=</stringProp>
        </elementProp>
      </collectionProp>
    </Arguments>
    
  2. Référencez la variable définie par l’utilisateur dans le script de test.

    Vous pouvez utiliser la syntaxe ${} pour faire référence à la variable dans le script. Dans l’exemple suivant, la variable udv_webapp est utilisée pour configurer l’URL du point de terminaison d’application.

    <stringProp name="HTTPSampler.domain">${udv_webapp}</stringProp>
    

Configurer des variables d’environnement dans le test de charge Azure

Pour transmettre des variables d’environnement au script Apache JMeter, vous pouvez configurer le test de charge dans le portail Azure, dans le fichier de configuration de test YAML, ou directement dans le workflow CI/CD.

Important

Lorsque vous définissez la variable d’environnement pour le test de charge, son nom doit correspondre au nom de la variable que vous avez utilisée dans le script Apache JMeter.

Pour spécifier une variable d’environnement pour le test de charge à l’aide du portail Azure, procédez comme suit :

  1. Sur la page de configuration de test, sélectionnez l’onglet Paramètres.

  2. Dans la section Variables d’environnement, entrez le nom et la valeur de la variable d’environnement, puis sélectionnez Appliquer.

    Screenshot that shows how to add an environment variable to a load test in the Azure portal.

Si vous exécutez votre test de charge dans un workflow CI/CD, vous pouvez définir des variables d’environnement dans le fichier de configuration de test YAML. Pour plus d’informations sur la syntaxe, consultez la page de référence sur le test de configuration YAML.

Vous pouvez également spécifier directement les variables d’environnement dans la définition du workflow CI/CD. Utilisez les paramètres d’entrée pour l’action de test de charges Azure ou la tâche Azure Pipelines pour transmettre des variables d’environnement au script Apache JMeter.

L’extrait de code YAML suivant est un exemple issu de la fonctionnalité GitHub Actions :

- name: 'Azure Load Testing'
  uses: azure/load-testing
  with:
    loadtestConfigFile: 'SampleApp.yaml'
    loadtestResource: 'MyTest'
    resourceGroup: 'loadtests-rg'
    env: |
    [
        {
        "name": "webapp",
        "value": "myapplication.contoso.com"
        }
    ]

L’extrait de code YAML suivant est un exemple issu d’Azure Pipelines :

- task: AzureLoadTest@1
  inputs:
    azureSubscription: 'MyAzureLoadTestingRG'
    loadTestConfigFile: 'SampleApp.yaml'
    loadTestResource: 'MyTest'
    resourceGroup: 'loadtests-rg'
    env: |
      [
          {
          "name": "webapp",
          "value": "myapplication.contoso.com"
          }
      ]

FAQ

Le service de test de charge Azure stocke-t-il mes valeurs de secrets ?

Non. Le service de test de charge Azure ne stocke pas les valeurs des secrets. Lorsque vous utilisez un URI de secret de coffre de clés, le service stocke uniquement l’URI du secret et récupère la valeur du secret pour chaque série de tests. Si vous fournissez la valeur des secrets dans un workflow CI/CD, les valeurs des secrets ne sont pas disponibles après la série de tests. Vous fournissez ces valeurs pour chaque exécution de test.

Que se passe-t-il s’il y a des paramètres dans le fichier de configuration YAML et dans le workflow CI/CD ?

Si un paramètre existe dans le fichier de configuration YAML et dans l’action Test de charge Azure ou la tâche Azure Pipelines, la valeur du flux de travail CI/CD est utilisée pour l’exécution de test.

J’ai créé et exécuté un test à partir de mon workflow CI/CD en transmettant des paramètres à l’aide de la tâche ou de l’action de test de charge Azure. Puis-je exécuter ce test à partir du portail Azure avec les mêmes paramètres ?

Les valeurs des paramètres ne sont pas stockées lorsqu’elles sont transmises à partir du workflow CI/CD. Vous devez à nouveau fournir les valeurs de paramètre lorsque vous exécutez le test à partir du Portail Azure. Vous obtenez une invite pour entrer les valeurs manquantes. Pour les valeurs secrètes, vous entrez l’URI du secret du coffre de clés. Les valeurs que vous entrez au niveau de la série de tests ou de la page de réexécution sont valides uniquement pour cette série de tests. Pour apporter des modifications au niveau du test, accédez à Configurer le test et entrez les valeurs de vos paramètres.