Konfigurieren einer Pipeline und Pushupdates

  • Artikel

In diesem Artikel erfahren Sie, wie Sie die Azure Developer CLI (azd) verwenden, um Vorlagenänderungen über eine CI/CD-Pipeline wie GitHub Actions oder Azure DevOps zu übertragen. In diesem Beispiel verwenden Sie die React-Web-App mit Node.js API und MongoDB auf Azure-Vorlage, aber Sie können die in diesem Artikel beschriebenen Prinzipien auf eine der Azure Developer CLI-Vorlagen anwenden.

Hinweis

Der azd pipeline config-Befehl befindet sich noch in der Betaversion. Weitere Informationen zur Unterstützung von Alpha- und Betafeatures finden Sie auf der Seite Featureversionsverwaltung und Releasestrategie.

Voraussetzungen

azd Vorlagen können eine standardmäßige GitHub Actions- und/oder Azure DevOps-Pipelinekonfigurationsdatei namens azure-dev.yml enthalten, die zum Einrichten von CI/CD erforderlich ist. Diese Konfigurationsdatei enthält Ihre Azure-Ressourcen und stellt Ihren Code in der Hauptverzweigung bereit. Sie finden azure-dev.yml:

  • Für GitHub Actions: im .github/workflows Verzeichnis.
  • Für Azure DevOps: im .azdo/pipelines Verzeichnis.

Sie können die Konfigurationsdatei wie vorliegend verwenden oder an Ihre Anforderungen anpassen.

Hinweis

Stellen Sie sicher, dass Ihre Vorlage eine Pipeline-Definition (azure-dev.yaml) enthält, bevor Sie azd pipeline config anfordern. azd erstellt diese Datei nicht automatisch. Siehe Erstellen einer Pipelinedefinition für azd weiter unten.

Nutzen Sie den azd pipeline config-Befehl zum Konfigurieren einer CI/CD-Pipeline, die die folgenden Aufgaben übernimmt:

  • Erstellen und Konfigurieren eines Dienstprinzipals für die App im Azure-Abonnement. Ihr Benutzer muss entweder die Rolle Owner oder die Rollen Contributor + User Access Administrator z innerhalb des Azure-Abonnements haben, damit azd Rollen erstellen und dem Dienstprinzipal zuweisen kann.
  • Führt Sie durch einen Workflow, um ein GitHub- oder Azure DevOps-Repository zu erstellen und zu konfigurieren und ihren Projektcode darin zu committen. Sie können auch ein vorhandenes Repository verwenden.
  • Erstellt eine sichere Verbindung zwischen Azure und Ihrem Repository.
  • Führt die GitHub-Aktion aus, wenn Sie die Workflowdatei einchecken.

Für eine genauere Kontrolle über diesen Prozess oder wenn der Benutzer nicht über die erforderlichen Rollen verfügt, können Sie manuell eine Pipeline konfigurieren.

Wählen Sie Ihren bevorzugten Pipelineanbieter aus, um den Vorgang fortzusetzen:

Autorisieren von GitHub für die Bereitstellung in Azure

Um den Workflow zu konfigurieren, müssen Sie einen Dienstprinzipal für die Bereitstellung in Azure in Ihrem Auftrag aus einer GitHub-Aktion autorisieren. azd erstellt den Dienstprinzipal und Verbundanmeldeinformationen dafür.

  1. Führen Sie den folgenden Befehl aus, um den Azure-Dienstprinzipal zu erstellen und die Pipeline zu konfigurieren:

    azd pipeline config

    Mit diesem Befehl wird optional ein GitHub-Repository erstellt und Code an das neue Repository übertragen.

    Hinweis

    Standardmäßig verwendet azd pipeline config OpenID Connect (OIDC) und ruft die Verbundanmeldeinformationen auf. Wenn Sie OIDC nicht verwenden möchten, führen Sie azd pipeline config --auth-type client-credentials aus.

    Die OIDC/Verbundanmeldeinformationen werden für Terraform nicht unterstützt.

    Erhalten Sie weitere Informationen zur OIDC-Unterstützung in azd.

  2. Geben Sie die angeforderten GitHub-Informationen an.

  3. Geben Sie y an, wenn Sie aufgefordert werden, die lokalen Änderungen zu übernehmen und zu pushen, um eine neue Ausführung von GitHub Actions zu starten.

  4. Zeigen Sie im Terminalfenster die Ergebnisse des azd pipeline config-Befehls an. Der azd pipeline config-Befehl gibt den GitHub-Repositorynamen für Ihr Projekt aus.

  5. Öffnen Sie im Browser das GitHub-Repository für Ihr Projekt.

  6. Wählen Sie Aktionen aus, um den ausgeführten Workflow anzuzeigen.

    Screenshot des ausgeführten GitHub-Workflows.

Vornehmen und Pushen einer Codeänderung

  1. Öffnen Sie im /src/web/src/layout-Verzeichnis des Projekts header.tsx.

  2. Suchen Sie die Zeile <Text variant="xLarge">ToDo</Text>.

  3. Ändern Sie das Literal ToDo in myTodo.

  4. Speichern Sie die Datei .

  5. Committen Sie die Änderung. Beim Commit der Änderung wird die GitHub Action-Pipeline gestartet, um das Update bereitzustellen.

    Screenshot der Schritte, die erforderlich sind, um Änderungen an der Testdatei vorzunehmen und zu übernehmen.

  6. Öffnen Sie im Browser das GitHub-Repository Ihres Projekts, um Folgendes anzuzeigen:

    • Ihr Commit
    • Der Commit von GitHub Actions, die eingerichtet werden.

    Screenshot Ihrer zugesicherten Änderung in GitHub.

  7. Wählen Sie Aktionen aus, um die im Workflow wiedergegebene Testaktualisierung anzuzeigen.

    Screenshot des GitHub-Workflows, der nach dem Testupdate ausgeführt wird.

  8. Besuchen Sie die Web-Frontend-URL, um das Update zu prüfen.

azd als eine GitHub-Aktion

Fügen Sie azd als eine GitHub-Aktion hinzu. Diese Aktion installiert azd. Um dies zu verwenden, müssen Sie .github\workflows\azure-dev.yml Folgendes hinzufügen:

on: [push]

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

Bereinigen von Ressourcen

Wenn Sie die in diesem Artikel erstellten Azure-Ressourcen nicht mehr benötigen, führen Sie den folgenden Befehl aus:

azd down

Erweiterte Funktionen

Sie können den azd pipeline config-Befehl für bestimmte Vorlagenszenarien oder Anforderungen erweitern, wie in den folgenden Abschnitten beschrieben.

Weitere geheime Schlüssel oder Variablen

Standardmäßig legt azd Variablen und geheime Schlüssel für die Pipeline fest. Beispielsweise erstellt der azd pipeline config-Befehl subscription id, environment name und region als Pipelinevariablen, jedes Mal wenn er ausgeführt wird. Die Pipelinedefinition verweist dann auf diese Variablen:

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

Wenn die Pipeline ausgeführt wird, ruft azd die Werte aus der Umgebung ab, die den Variablen und geheimen Schlüsseln zugeordnet sind. Je nach Vorlage gibt es möglicherweise Einstellungen, die Sie mithilfe von Umgebungsvariablen steuern können. Beispielsweise könnte eine Umgebungsvariable namens KEY_VAULT_NAME festgelegt werden, um den Namen einer Key Vault-Ressource innerhalb der Vorlageninfrastruktur zu definieren. In solchen Fällen kann die Liste der Variablen und geheimen Schlüssel mithilfe der azure.yaml-Vorlage definiert werden. Sehen Sie sich beispielsweise die folgende azure.yaml-Konfiguration an:

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

Bei dieser Konfiguration überprüft azd, ob eine der Variablen oder geheimen Schlüssel einen nicht leeren Wert in der Umgebung aufweist. azd erstellt anschließend entweder eine Variable oder ein geheimer Schlüssel für die Pipeline, wobei der Name des Schlüssels in der Konfiguration als Name der Variablen oder des geheimen Schlüssels und der Wert, der nicht aus der Umgebung für den Wert stammt, verwendet wird.

Die azure-dev.yaml-Pipelinedefinition kann dann auf die Variablen oder geheimen Schlüssel verweisen:

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

Hinweis

Sie müssen azd pipeline config ausführen, nachdem die Liste der geheimen Schlüssel oder der Variablen in azure.yaml aktualisiert wurde, damit azd die Pipelinewerte zurücksetzen kann.

Infrastrukturparameter

Sehen Sie sich das folgende Bicep-Beispiel an:

@secure()
param BlobStorageConnection string

Der Parameter BlobStorageConnection hat keinen Standardwert festgelegt, daher fordert azd den Benutzer auf, einen Wert einzugeben. Während CI/CD gibt es jedoch keine interaktive Eingabeaufforderung. azd muss den Wert für den Parameter anfordern, wenn Sie azd pipeline config ausführen, den Wert in der Pipeline speichern und den Wert dann erneut abrufen, wenn die Pipeline ausgeführt wird.

azd verwendet einen Pipelineschlüssel namens AZD_INITIAL_ENVIRONMENT_CONFIG, der aufgerufen wird, um den Wert aller erforderlichen Parameter in der Pipeline automatisch zu speichern und festzulegen. Sie müssen nur auf diesen geheimen Schlüssel in Ihrer Pipeline verweisen:

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

Wenn die Pipeline ausgeführt wird, verwendet azd die Werte für die Parameter aus dem geheimen Schlüssel, womit die Notwendigkeit einer interaktiven Eingabeaufforderung entfällt.

Hinweis

Sie müssen azd pipeline config erneut ausführen, wenn Sie einen neuen Parameter hinzufügen.

Erstellen einer Pipelinedefinition

Wenn Ihre azd-Vorlage noch nicht über eine CI/CD-Pipelinedefinitionsdatei verfügt, können Sie eine Vorlage selbst erstellen. Eine CI/CD-Pipelinedefinition weist in der Regel vier Hauptabschnitte auf:

  • Trigger (trigger)
  • konfigurieren
  • Betriebssystem oder Pool
  • auszuführende Schritte

Die folgenden Beispiele veranschaulichen, wie Sie eine Definitionsdatei und zugehörige Konfigurationen für GitHub-Aktionen und Azure-Pipelines erstellen.

Für die Ausführung von azd in GitHub-Aktionen sind die folgenden Konfigurationen erforderlich:

  • Gewähren Sie id-token: write und contents: read Zugriffsbereiche.
  • Installieren Sie die azd-Aktion, es sei denn, Sie verwenden ein Docker-Image, auf dem azd bereits installiert ist.

Sie können die folgende Vorlage als Ausgangspunkt für Ihre eigene Pipelinedefinition verwenden:

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