Delen via

Een pijplijn en push-updates configureren

  • Artikel

In dit artikel leert u hoe u de Azure Developer CLI (azd) gebruikt om sjabloonwijzigingen te pushen via een CI/CD-pijplijn, zoals GitHub Actions of Azure DevOps. In dit voorbeeld gebruikt u de React-web-app met Node.js API en MongoDB in Azure-sjablonen , maar u kunt de principes die u in dit artikel leert toepassen op een van de Azure Developer CLI-sjablonen.

Notitie

De azd pipeline config opdracht bevindt zich nog steeds in de bètaversie. Lees meer over ondersteuning voor alfa- en bètafuncties op de pagina met functieversiebeheer en releasestrategie .

Vereisten

azd sjablonen kunnen al dan niet een standaard GitHub Actions- en/of Azure DevOps-pijplijnconfiguratiebestand bevatten, azure-dev.ymldat vereist is voor het instellen van CI/CD. Dit configuratiebestand richt uw Azure-resources in en implementeert uw code in de hoofdbranch. U kunt het volgende vinden azure-dev.yml:

  • Voor GitHub Actions: in de .github/workflows map.
  • Voor Azure DevOps: in de .azdo/pipelines map.

U kunt het configuratiebestand naar wens gebruiken of aanpassen aan uw behoeften.

Notitie

Zorg ervoor dat uw sjabloon een pijplijndefinitie (azure-dev.yaml) heeft voordat u aanroept azd pipeline config. azd maakt dit bestand niet automatisch. Zie Hieronder een pijplijndefinitie maken voor azd .

Gebruik de azd pipeline config opdracht om een CI/CD-pijplijn te configureren, waarmee de volgende taken worden verwerkt:

  • Hiermee maakt en configureert u een service-principal voor de app in het Azure-abonnement. Uw gebruiker moet een Owner rol of Contributor + User Access Administrator rollen hebben binnen het Azure-abonnement, zodat azd rollen kan maken en toewijzen aan de service-principal.
  • Stapsgewijs doorloopt u een werkstroom om een GitHub- of Azure DevOps-opslagplaats te maken en te configureren en uw projectcode hierin door te voeren. U kunt er ook voor kiezen om een bestaande opslagplaats te gebruiken.
  • Hiermee maakt u een beveiligde verbinding tussen Azure en uw opslagplaats.
  • Hiermee wordt de GitHub-actie uitgevoerd wanneer u het werkstroombestand incheckt.

Voor gedetailleerdere controle over dit proces of als u de vereiste rollen niet hebt, kunt u handmatig een pijplijn configureren.

Selecteer de gewenste pijplijnprovider om door te gaan:

GitHub autoriseren om te implementeren in Azure

Als u de werkstroom wilt configureren, moet u een service-principal autoriseren om namens u in Azure te implementeren vanuit een GitHub-actie. azd maakt de service-principal en een federatieve referentie voor deze principal.

  1. Voer de volgende opdracht uit om de Azure-service-principal te maken en de pijplijn te configureren:

    azd pipeline config

    Met deze opdracht maakt u eventueel een GitHub-opslagplaats en pusht u code naar de nieuwe opslagplaats.

    Notitie

    Maakt standaard azd pipeline config gebruik van OpenID Connect (OIDC), genaamd federatieve referenties. Als u liever geen OIDC gebruikt, voert u azd pipeline config --auth-type client-credentials uit.

    OIDC/federatieve referenties worden niet ondersteund voor Terraform.

    Meer informatie over OIDC-ondersteuning in azd.

  2. Geef de aangevraagde GitHub-gegevens op.

  3. Wanneer u wordt gevraagd of u uw lokale wijzigingen doorvoert en pusht om een nieuwe Uitvoering van GitHub Actions te starten, geeft u yop.

  4. Bekijk de resultaten van de azd pipeline config opdracht in het terminalvenster. Met azd pipeline config de opdracht wordt de naam van de GitHub-opslagplaats voor uw project uitgevoerd.

  5. Open in uw browser de GitHub-opslagplaats voor uw project.

  6. Selecteer Acties om de werkstroom uit te voeren.

    Schermopname van de actieve GitHub-werkstroom.

Een codewijziging maken en pushen

  1. Open header.tsxde map van /src/web/src/layout het project.

  2. Zoek de regel <Text variant="xLarge">ToDo</Text>.

  3. Wijzig de letterlijke tekst ToDo in myTodo.

  4. Sla het bestand op.

  5. Voer uw wijziging door. Als u de wijziging doorvoert, wordt de GitHub Action-pijplijn gestart om de update te implementeren.

    Schermopname van de stappen die nodig zijn om een wijziging in het testbestand aan te brengen en door te voeren.

  6. Open in uw browser de GitHub-opslagplaats van uw project om beide te zien:

    • Uw doorvoer
    • De doorvoering van GitHub Actions die wordt ingesteld.

    Schermopname van uw doorgevoerde wijziging in GitHub.

  7. Selecteer Acties om de testupdate weer te geven die in de werkstroom wordt weergegeven.

    Schermopname van de GitHub-werkstroom die wordt uitgevoerd na de testupdate.

  8. Ga naar de front-end-URL van het web om de update te controleren.

azd als een GitHub-actie

Toevoegen azd als een GitHub-actie. Met deze actie wordt geïnstalleerd azd. Als u deze wilt gebruiken, kunt u het volgende toevoegen aan .github\workflows\azure-dev.yml:

on: [push]

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

Resources opschonen

Wanneer u de Azure-resources die in dit artikel zijn gemaakt niet meer nodig hebt, voert u de volgende opdracht uit:

azd down

Geavanceerde functies

U kunt de azd pipeline config opdracht uitbreiden voor specifieke sjabloonscenario's of vereisten, zoals beschreven in de volgende secties.

Aanvullende geheimen of variabelen

azd Stelt standaard variabelen en geheimen in voor de pijplijn. Met de azd pipeline config opdracht wordt bijvoorbeeld de subscription iden environment name de region als pijplijnvariabelen gemaakt wanneer deze wordt uitgevoerd. De pijplijndefinitie verwijst vervolgens naar deze variabelen:

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

Wanneer de pijplijn wordt uitgevoerd, azd worden de waarden opgehaald uit de omgeving, die is toegewezen aan de variabelen en geheimen. Afhankelijk van de sjabloon zijn er mogelijk instellingen die u kunt beheren met behulp van omgevingsvariabelen. Een omgevingsvariabele met de naam KEY_VAULT_NAME kan bijvoorbeeld worden ingesteld om de naam van een Key Vault-resource in de sjablooninfrastructuur te definiëren. In dergelijke gevallen kan de lijst met variabelen en geheimen worden gedefinieerd met behulp van de azure.yamlsjabloon. Denk bijvoorbeeld aan de volgende azure.yaml configuratie:

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

Met deze configuratie azd controleert u of een van de variabelen of geheimen een niet-lege waarde in de omgeving heeft. azd maakt vervolgens een variabele of een geheim voor de pijplijn met behulp van de naam van de sleutel in de configuratie als de naam van de variabele of het geheim en de niet-tekenreekswaarde uit de omgeving voor de waarde.

De azure-dev.yaml pijplijndefinitie kan vervolgens verwijzen naar de variabelen of geheimen:

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

Notitie

U moet worden uitgevoerd azd pipeline config na het bijwerken van de lijst met geheimen of variabelen in azure.yaml azd om de pijplijnwaarden opnieuw in te stellen.

Infrastructuurparameters

Bekijk het volgende bicep-voorbeeld:

@secure()
param BlobStorageConnection string

De parameter BlobStorageConnection heeft geen standaardwaarde ingesteld, dus azd vraagt de gebruiker om een waarde in te voeren. Er is echter geen interactieve prompt tijdens CI/CD. azd moet de waarde voor de parameter aanvragen wanneer u uitvoert azd pipeline config, sla de waarde op in de pijplijn en haal de waarde opnieuw op wanneer de pijplijn wordt uitgevoerd.

azd gebruikt een pijplijngeheim dat wordt aangeroepen AZD_INITIAL_ENVIRONMENT_CONFIG om automatisch de waarde van alle vereiste parameters in de pijplijn op te slaan en in te stellen. U hoeft alleen naar dit geheim in uw pijplijn te verwijzen:

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

Wanneer de pijplijn wordt uitgevoerd, azd worden de waarden voor de parameters uit het geheim opgehaald, waardoor er geen interactieve prompt meer nodig is.

Notitie

U moet opnieuw uitvoeren azd pipeline config als u een nieuwe parameter toevoegt.

Een pijplijndefinitie maken

Als uw azd sjabloon nog geen CI/CD-pijplijndefinitiebestand heeft, kunt u er zelf een maken. Een CI/CD-pijplijndefinitie heeft doorgaans vier hoofdsecties:

  • activeren
  • permissions
  • besturingssysteem of pool
  • stappen die moeten worden uitgevoerd

In de volgende voorbeelden ziet u hoe u een definitiebestand en gerelateerde configuraties maakt voor GitHub Actions en Azure Pipelines.

Voor uitvoering azd in GitHub Actions zijn de volgende configuraties vereist:

  • Toegangsbereiken verlenen id-token: write en contents: read openen.
  • Installeer de azd-actie, tenzij u een docker-installatiekopieën gebruikt waarvoor azd al is geïnstalleerd.

U kunt de volgende sjabloon gebruiken als uitgangspunt voor uw eigen pijplijndefinitie:

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