Partage via

Configuration d'un pipeline et push des mises à jour

  • Article

Dans cet article, vous apprendrez à utiliser l'Azure Developer CLI (azd) pour pousser des modifications de modèles via un pipeline CI/CD tel que GitHub Actions ou Azure DevOps. Pour cet exemple, vous utiliserez le modèle React Web App avec API Node.js et MongoDB sur Azure, mais vous pouvez appliquer les principes que vous apprenez dans cet article à n'importe quel modèle Azure Developer CLI.

Remarque

La commande azd pipeline config est encore en version bêta. Pour en savoir plus sur la prise en charge des fonctionnalités alpha et bêta, consultez la page sur le versionnement des fonctionnalités et la stratégie de sortie.

Prérequis

Les azdmodèles peuvent inclure ou non un fichier de configuration par défaut des actions GitHub et/ou du pipeline Azure DevOps appelé azure-dev.yml, qui est nécessaire pour configurer le CI/CD. Ce fichier de configuration provisionne vos ressources Azure et déploie votre code sur la branche principale. Vous pouvez trouver azure-dev.yml :

  • Pour les actions GitHub: dans le répertoire .github/workflows.
  • Pour Azure DevOps : dans le répertoire .azdo/pipelines.

Vous pouvez utiliser le fichier de configuration tel quel ou le modifier en fonction de vos besoins.

Remarque

Assurez-vous que votre modèle possède une définition de pipeline (azure-dev.yaml) avant d’appeler azd pipeline config. azd ne créera pas automatiquement ce fichier. Voir Créer une définition de pipeline pour azd ci-dessous.

Pour configurer un pipeline CI/CD, utilisez la commande azd pipeline config, qui prend en charge les tâches suivantes :

  • Crée et configure un principal de service pour l’application sur l’abonnement Azure. Votre utilisateur doit avoir un rôle Owner ou des rôles Contributor + User Access Administrator dans l’abonnement Azure car pour permettre à azd de créer et d’attribuer des rôles au principal de service.
  • Vous guide dans un workflow pour créer et configurer un référentiel GitHub ou Azure DevOps et y livrer le code de votre projet. Vous pouvez également choisir d'utiliser un référentiel existant.
  • Crée une connexion sécurisée entre Azure et votre référentiel.
  • Exécute l'action GitHub lorsque vous enregistrez le fichier de workflow.

Pour un contrôle plus granulaire de ce processus, ou si votre utilisateur ne dispose pas des rôles requis, vous pouvez configurer manuellement un pipeline.

Sélectionnez votre fournisseur de pipeline préféré pour continuer :

Autoriser GitHub à déployer sur Azure

Pour configurer le workflow, vous devez autoriser un principal de service à déployer vers Azure en votre nom, à partir d'une action GitHub. azd crée le principal de service et un justificatif d'identité fédéré pour lui.

  1. Exécutez la commande suivante pour créer le principal de service Azure et configurer le pipeline :

    azd pipeline config

    Cette commande, en option, crée un référentiel GitHub et pousse le code vers le nouveau référentiel.

    Remarque

    Par défaut, azd pipeline config utilise OpenID Connect (OIDC), appelé informations d'identification fédérées. Si vous préférez ne pas utiliser OIDC, exécutez azd pipeline config --auth-type client-credentials.

    Les identifiants OIDC/fédérés ne sont pas pris en charge pour Terraform.

    Pour en savoir plus sur le soutien de l'OIDC, voir azd.

  2. Fournissez les informations GitHub requises.

  3. Lorsque vous êtes invité à commettre et à pousser vos modifications locales pour démarrer une nouvelle exécution d'actions GitHub, indiquez y.

  4. Dans la fenêtre du terminal, visualisez les résultats de la commande azd pipeline config. La commande azd pipeline config affichera le nom du référentiel GitHub de votre projet.

  5. À l'aide de votre navigateur, ouvrez le référentiel GitHub de votre projet.

  6. Sélectionnez Actions pour voir le workflow s'exécuter.

    Capture d'écran du workflow GitHub en cours d'exécution.

Effectuer et pousser une modification de code

  1. Dans le répertoire /src/web/src/layout du projet, ouvrez header.tsx.

  2. Localisez la ligne <Text variant="xLarge">ToDo</Text>.

  3. Remplacez le texte littéral ToDo par myTodo.

  4. Enregistrez le fichier.

  5. Validez votre modification. La validation de la modification démarre le pipeline d'actions GitHub pour déployer la mise à jour.

    Capture d'écran des étapes nécessaires pour apporter et valider une modification au fichier de test.

  6. À l'aide de votre navigateur, ouvrez le référentiel GitHub de votre projet pour voir les deux :

    • Votre validation
    • La validation des actions GitHub en cours de mise en place.

    Capture d'écran de votre modification validée dans GitHub.

  7. Sélectionnez Actions pour voir la mise à jour du test reflétée dans le workflow.

    Capture d'écran du workflow GitHub en cours d'exécution après la mise à jour du test.

  8. Visitez l'URL du Web frontend pour inspecter la mise à jour.

azd en tant qu'action GitHub

Ajoutez azd en tant qu'action GitHub. Cette action installera azd. Pour l'utiliser, vous pouvez ajouter ce qui suit à .github\workflows\azure-dev.yml :

on: [push]

jobs:
   build:
      runs-on: ubuntu-latest
      steps:
         - name: Install azd
         uses: Azure/setup-azd@v0.1.0

Nettoyer les ressources

Lorsque vous n'avez plus besoin des ressources Azure créées dans cet article, exécutez la commande suivante :

azd down

Fonctionnalités avancées

Vous pouvez étendre la commande azd pipeline config pour des scénarios ou des besoins spécifiques en matière de modèles, comme décrit dans les sections suivantes.

Secrets ou variables supplémentaires

Par défaut, azd définit les variables et les secrets du pipeline. Par exemple, la commande azd pipeline config crée les variables subscription id, environment name et region comme variables de pipeline à chaque fois qu'elle s'exécute. La définition du pipeline fait alors référence à ces variables :

env:
   AZURE_CLIENT_ID: ${{ vars.AZURE_CLIENT_ID }}
   AZURE_TENANT_ID: ${{ vars.AZURE_TENANT_ID }}
   AZURE_SUBSCRIPTION_ID: ${{ vars.AZURE_SUBSCRIPTION_ID }}
   AZURE_ENV_NAME: ${{ vars.AZURE_ENV_NAME }}
   AZURE_LOCATION: ${{ vars.AZURE_LOCATION }}

Lorsque le pipeline s'exécute, azd obtient les valeurs de l'environnement, qui sont mappées aux variables et aux secrets. Selon le modèle, il peut y avoir des paramètres que vous pouvez contrôler à l'aide de variables d'environnement. Par exemple, une variable d'environnement nommée KEY_VAULT_NAME peut être définie pour définir le nom d'une ressource Key Vault dans l'infrastructure du modèle. Dans ce cas, la liste des variables et des secrets peut être définie par le modèle, à l'aide de l'élément azure.yaml. Par exemple, considérez la configuration azure.yaml suivante :

pipeline:
  variables:
    - KEY_VAULT_NAME
    - STORAGE_NAME
  secrets:
    - CONNECTION_STRING

Avec cette configuration, azd vérifie si l'une des variables ou l'un des secrets a une valeur non vide dans l'environnement. azd crée ensuite une variable ou un secret pour le pipeline en utilisant le nom de la clé dans la configuration comme nom de la variable ou du secret, et la valeur non chaîne de l'environnement pour la valeur.

La définition du pipeline azure-dev.yaml peut alors faire référence aux variables ou aux secrets :

- name: Provision Infrastructure
   run: azd provision --no-prompt
   env:
      KEY_VAULT_NAME: ${{ variables.KEY_VAULT_NAME }}
      STORAGE_NAME: ${{ variables.STORAGE_NAME }}
      CONNECTION_STRING: ${{ secrets.CONNECTION_STRING }}

Remarque

Vous devez exécuter azd pipeline config après avoir mis à jour la liste des secrets ou des variables dans azure.yaml pour que azd réinitialise les valeurs du pipeline.

Paramètres d’infrastructure

Prenons l'exemple suivant du biceps :

@secure()
param BlobStorageConnection string

Le paramètre BlobStorageConnection n'ayant pas de valeur par défaut définie, azd invite l'utilisateur à saisir une valeur. Cependant, il n'y a pas de requête interactive pendant le CI/CD. azd doit demander la valeur du paramètre lorsque vous exécutez azd pipeline config, enregistrer la valeur dans le pipeline, puis récupérer la valeur à nouveau lors de l'exécution du pipeline.

azd utilise un secret de pipeline appelé AZD_INITIAL_ENVIRONMENT_CONFIG pour enregistrer et définir automatiquement la valeur de tous les paramètres requis dans le pipeline. Il vous suffit de référencer ce secret dans votre pipeline :

- name: Provision Infrastructure
   run: azd provision --no-prompt
   env:
      AZD_INITIAL_ENVIRONMENT_CONFIG: ${{ secrets.AZD_INITIAL_ENVIRONMENT_CONFIG }}

Lorsque le pipeline s'exécute, azd prend les valeurs des paramètres dans le secret, ce qui supprime la nécessité d'une requête interactive.

Remarque

Vous devez réexécuter azd pipeline config si vous ajoutez un nouveau paramètre.

Créer une définition de pipeline

Si votre modèle azd ne dispose pas déjà d'un fichier de définition du pipeline CI/CD, vous pouvez en créer un vous-même. Une définition de pipeline CI/CD comporte généralement 4 sections principales :

  • trigger
  • autorisations
  • le système d'exploitation ou le pool
  • étapes à exécuter

Les exemples suivants montrent comment créer un fichier de définition et les configurations connexes pour GitHub Actions et Azure Pipelines.

L'exécution de azd dans GitHub Actions nécessite les configurations suivantes :

  • Accorder les portées d'accès id-token: write et contents: read.
  • Installez l'action azd, à moins que vous n'utilisiez une image docker où azd est déjà installée.

Vous pouvez utiliser le modèle suivant comme point de départ pour votre propre définition de pipeline :

on:
  workflow_dispatch:
  push:
    # Run when commits are pushed to mainline branch (main or master)
    # Set this to the mainline branch you are using
    branches:
      - main
      - master

# Set this permission if you are using a Federated Credential.
permissions:
  id-token: write
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    # azd build-in variables.
    # This variables are always set by `azd pipeline config`
    # You can set them as global env (apply to all steps) or you can add them to individual steps' environment
    env:
      AZURE_CLIENT_ID: ${{ vars.AZURE_CLIENT_ID }}
      AZURE_TENANT_ID: ${{ vars.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ vars.AZURE_SUBSCRIPTION_ID }}
      AZURE_ENV_NAME: ${{ vars.AZURE_ENV_NAME }}
      AZURE_LOCATION: ${{ vars.AZURE_LOCATION }}
      ## Define the additional variables or secrets that are required globally (provision and deploy)
      # ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
      # ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}      
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      # using the install-azd action
      - name: Install azd
        uses: Azure/setup-azd@v1.0.0

      # # If you want to use azd-daily build, or install it from a PR, you can remove previous step and
      # # use the next one:
      # - name: Install azd - daily or from PR
      #  # Update this scrip based on the OS - pool of your pipeline. This example is for a linux pipeline installing daily build
      #  run: curl -fsSL https://aka.ms/install-azd.sh | bash -s -- --version daily
      #  shell: pwsh

      # azd set up Federated Credential by default. You can remove this step if you are using Client Credentials
      - name: Log in with Azure (Federated Credentials)
        if: ${{ env.AZURE_CLIENT_ID != '' }}
        run: |
          azd auth login `
            --client-id "$Env:AZURE_CLIENT_ID" `
            --federated-credential-provider "github" `
            --tenant-id "$Env:AZURE_TENANT_ID"
        shell: pwsh

      ## If you set up your pipeline with Client Credentials, remove previous step and uncomment this one
      # - name: Log in with Azure (Client Credentials)
      #   if: ${{ env.AZURE_CREDENTIALS != '' }}
      #   run: |
      #     $info = $Env:AZURE_CREDENTIALS | ConvertFrom-Json -AsHashtable;
      #     Write-Host "::add-mask::$($info.clientSecret)"

      #     azd auth login `
      #       --client-id "$($info.clientId)" `
      #       --client-secret "$($info.clientSecret)" `
      #       --tenant-id "$($info.tenantId)"
      #   shell: pwsh
      #   env:
      #     AZURE_CREDENTIALS: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Provision Infrastructure
        run: azd provision --no-prompt
        env:
         #  # uncomment this if you are using infrastructure parameters
         #  AZD_INITIAL_ENVIRONMENT_CONFIG: ${{ secrets.AZD_INITIAL_ENVIRONMENT_CONFIG }}
         ## Define the additional variables or secrets that are required only for provision 
         #  ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
         #  ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}

      - name: Deploy Application
        run: azd deploy --no-prompt
        env:
         ## Define the additional variables or secrets that are required only for deploy
         #  ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
         #  ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}