Condividi tramite

Configurare una pipeline e gli aggiornamenti push

  • Articolo

Questo articolo illustra come usare l'interfaccia della riga di comando per sviluppatori di Azure (azd) per eseguire il push delle modifiche del modello tramite una pipeline CI/CD, ad esempio GitHub Actions o Azure DevOps. Per questo esempio si userà l'app Web React con Node.js API e MongoDB nel modello di Azure, ma è possibile applicare i principi appresi in questo articolo a uno dei modelli dell'interfaccia della riga di comando per sviluppatori di Azure.

Nota

Il azd pipeline config comando è ancora in versione beta. Altre informazioni sul supporto delle funzionalità alfa e beta sono disponibili nella pagina relativa al controllo delle versioni delle funzionalità e alla strategia di rilascio.

Prerequisiti

azd I modelli possono includere o meno un file di configurazione predefinito della pipeline GitHub Actions e/o Azure DevOps denominato azure-dev.yml, necessario per configurare CI/CD. Questo file di configurazione effettua il provisioning delle risorse di Azure e distribuisce il codice nel ramo principale. È possibile trovare azure-dev.yml:

  • Per GitHub Actions: nella .github/workflows directory.
  • Per Azure DevOps: nella .azdo/pipelines directory.

È possibile usare il file di configurazione così come è o modificarlo in base alle proprie esigenze.

Nota

Assicurarsi che il modello abbia una definizione di pipeline (azure-dev.yaml) prima di chiamare azd pipeline config. azd non crea automaticamente questo file. Vedere Creare una definizione di pipeline per azd di seguito.

Usare il azd pipeline config comando per configurare una pipeline CI/CD che gestisce le attività seguenti:

  • Creazione e configurazione di un'entità servizio per l'app nella sottoscrizione di Azure. L'utente deve avere ruoli Owner o Contributor + User Access Administrator ruoli all'interno della sottoscrizione di Azure per consentire ad azd di creare e assegnare ruoli all'entità servizio.
  • È possibile eseguire un flusso di lavoro per creare e configurare un repository GitHub o Azure DevOps ed eseguirne il commit. È anche possibile scegliere di usare un repository esistente.
  • Crea una connessione sicura tra Azure e il repository.
  • Esegue l'azione GitHub quando si archivia il file del flusso di lavoro.

Per un controllo più granulare su questo processo o se l'utente non dispone dei ruoli necessari, è possibile configurare manualmente una pipeline.

Selezionare il provider di pipeline preferito per continuare:

Autorizzare GitHub a eseguire la distribuzione in Azure

Per configurare il flusso di lavoro, è necessario autorizzare un'entità servizio a eseguire la distribuzione in Azure per conto dell'utente da un'azione GitHub. azd crea l'entità servizio e una credenziale federata.

  1. Eseguire il comando seguente per creare l'entità servizio di Azure e configurare la pipeline:

    azd pipeline config

    Questo comando, facoltativamente, crea un repository GitHub ed esegue il push del codice nel nuovo repository.

    Nota

    Per impostazione predefinita, azd pipeline config usa OpenID Connect (OIDC), denominate credenziali federate . Se si preferisce non usare OIDC, eseguire azd pipeline config --auth-type client-credentials.

    Le credenziali OIDC/federate non sono supportate per Terraform.

    Altre informazioni sul supporto OIDC in azd.

  2. Specificare le informazioni di GitHub richieste.

  3. Quando viene richiesto di eseguire il commit e il push delle modifiche locali per avviare una nuova esecuzione di GitHub Actions, specificare y.

  4. Nella finestra del terminale visualizzare i risultati del azd pipeline config comando. Il azd pipeline config comando restituirà il nome del repository GitHub per il progetto.

  5. Usando il browser, aprire il repository GitHub per il progetto.

  6. Selezionare Azioni per visualizzare il flusso di lavoro in esecuzione.

    Screenshot del flusso di lavoro GitHub in esecuzione.

Apportare ed eseguire il push di una modifica del codice

  1. Nella directory del /src/web/src/layout progetto aprire header.tsx.

  2. Individuare la riga <Text variant="xLarge">ToDo</Text>.

  3. Modificare il valore letterale ToDo in myTodo.

  4. Salvare il file.

  5. Eseguire il commit della modifica. Il commit della modifica avvia la pipeline di GitHub Action per distribuire l'aggiornamento.

    Screenshot dei passaggi necessari per apportare ed eseguire il commit della modifica al file di test.

  6. Usando il browser, aprire il repository GitHub del progetto per visualizzare entrambi:

    • Commit
    • Commit da GitHub Actions configurato.

    Screenshot della modifica di cui è stato eseguito il commit in GitHub.

  7. Selezionare Azioni per visualizzare l'aggiornamento del test che si riflette nel flusso di lavoro.

    Screenshot del flusso di lavoro GitHub in esecuzione dopo l'aggiornamento dei test.

  8. Visitare l'URL front-end Web per controllare l'aggiornamento.

azd come azione di GitHub

Aggiungere azd come azione GitHub. Questa azione installerà azd. Per usarlo, è possibile aggiungere quanto segue a .github\workflows\azure-dev.yml:

on: [push]

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

Pulire le risorse

Quando le risorse di Azure create in questo articolo non sono più necessarie, eseguire il comando seguente:

azd down

Funzionalità avanzate

È possibile estendere il azd pipeline config comando per scenari o requisiti di modello specifici, come descritto nelle sezioni seguenti.

Segreti o variabili aggiuntivi

Per impostazione predefinita, azd imposta variabili e segreti per la pipeline. Ad esempio, il azd pipeline config comando crea le subscription idvariabili , environment name e come variabili della region pipeline ogni volta che viene eseguita. La definizione della pipeline fa quindi riferimento a tali variabili:

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 }}

Quando la pipeline viene eseguita, azd ottiene i valori dall'ambiente, di cui viene eseguito il mapping alle variabili e ai segreti. A seconda del modello, potrebbero essere presenti impostazioni che è possibile controllare usando le variabili di ambiente. Ad esempio, una variabile di ambiente denominata KEY_VAULT_NAME può essere impostata per definire il nome di una risorsa key vault all'interno dell'infrastruttura modello. Per questi casi, l'elenco di variabili e segreti può essere definito dal modello, usando .azure.yaml Si consideri ad esempio la configurazione seguente azure.yaml :

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

Con questa configurazione, azd controlla se una delle variabili o dei segreti ha un valore non vuoto nell'ambiente. azd crea quindi una variabile o un segreto per la pipeline usando il nome della chiave nella configurazione come nome della variabile o del segreto e il valore non stringa dell'ambiente per il valore.

La definizione della azure-dev.yaml pipeline può quindi fare riferimento alle variabili o ai segreti:

- 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 }}

Nota

È necessario eseguire azd pipeline config dopo aver aggiornato l'elenco di segreti o variabili in azure.yaml per azd per reimpostare i valori della pipeline.

Parametri dell'infrastruttura

Si consideri l'esempio bicep seguente:

@secure()
param BlobStorageConnection string

Il parametro BlobStorageConnection non ha un valore predefinito impostato, quindi azd chiede all'utente di immettere un valore. Tuttavia, non viene visualizzata alcuna richiesta interattiva durante CI/CD. azd deve richiedere il valore per il parametro quando si esegue azd pipeline config, salvare il valore nella pipeline e quindi recuperare di nuovo il valore quando viene eseguita la pipeline.

azd usa un segreto della pipeline denominato AZD_INITIAL_ENVIRONMENT_CONFIG per salvare e impostare automaticamente il valore di tutti i parametri necessari nella pipeline. È sufficiente fare riferimento a questo segreto nella pipeline:

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

Quando la pipeline viene eseguita, azd accetta i valori per i parametri dal segreto, rimuovendo la necessità di un prompt interattivo.

Nota

È necessario eseguire azd pipeline config di nuovo se si aggiunge un nuovo parametro.

Creare una definizione di pipeline

Se il azd modello non ha già un file di definizione della pipeline CI/CD, è possibile crearne uno manualmente. Una definizione di pipeline CI/CD include in genere 4 sezioni principali:

  • trigger
  • autorizzazioni
  • sistema operativo o pool
  • passaggi da eseguire

Gli esempi seguenti illustrano come creare un file di definizione e le configurazioni correlate per GitHub Actions e Azure Pipelines.

L'esecuzione azd in GitHub Actions richiede le configurazioni seguenti:

  • Concedere id-token: write e contents: read accedere agli ambiti.
  • Installare l'azione azd, a meno che non si usi un'immagine Docker in cui azd è già installato.

È possibile usare il modello seguente come punto di partenza per la propria definizione della 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 }}